Copyright © 2005 Charlie Poole. All rights reserved Test First User Interfaces XP2005 Sheffield University June 18, 2005.

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Schedule 2:00-3:00Introduction Review of Testing Practices Is UI Testing Hard? Message of this Course 3:00Break 3:15-4:15Principles Patterns Practices 4:15Break 4:30-5:30Tools Techniques Conclusion

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Contact Email charlie@pooleconsulting.com cpoole@exoftware.com Web Sites www.charliepoole.org www.pooleconsulting.com Seattle XP Users Group www.seattlexp.org NUnit Testing Framework www.nunit.org

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Agile Development Modern software development methodologies increasingly emphasize agility. – Increased pace of development – Prevalence of unstable requirements Teams need to work as a cohesive unit, with strong communications and continuous feedback. Traditional communication channels often fail in this setting.

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Tests in XP Acceptance/Customer Tests – Tied to Requirements – Express customer intention Unit/Programmer Tests – Small units of functionality tested in isolation – Express programmer intention

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Tests as Communication For each test there is a message – Criterion for success – Result For each test there are two communicators – Whoever defines the test criteria – Whoever tries to satisfy the test criteria

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Tests Communicate Intent From the customer – What the application should do From the developer – How the application will do it

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Test-Driven Development A fundamental practice of XP But “extremely” valuable on it’s own Note that the term is overloaded –The practice of writing tests and then making them pass –The “inner cycle” which includes TDD as one element A three-step micro-cycle Make it Fail –No code without a failing test Make it Work –As simply as possible Make it Better –Refactor

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Effect of Continuous Testing The state of the application is known at all times – based on which tests pass. Requirements changes are accepted as a basic condition of development rather than being resisted. Resulting code is more robust and – with continuous integration – can be ready for demos or even delivery at any time.

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Automating Tests Tests must be automated if they are to be run as frequently as we need them to run. Tools like SUnit, JUnit, CPPUnit and NUnit provide a framework for automating unit tests. Tools like FIT and Exactor provide a framework for automating acceptance tests.

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Exercise What makes UI testing hard for you? Break into groups of three or four… – List things that make UI testing difficult – Identify general versus platform-specific issues – What would be needed to resolve each issue? Select one person to present your answers.

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved What Makes Testing Hard? Programmer tests aim at test independence But… Testing connected sets of objects is hard – Tests become dependent on one another – Objects have to be put in a known state – It’s hard to figure out what failed

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Problems of GUI Testing Tight coupling to other parts of the application – may include business logic UI is implemented as a single large program handling all user interaction Design is driven by IDE code generation Technical issues of the platform

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Possible Solutions Tight coupling to other parts of the application – may include business logic – Separate business logic from the UI – Use interfaces to permit substitution – Use factories to create business objects

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Possible Solutions UI is implemented as a single large program handling all user interaction – Use separate classes for UI logic – Use separate classes for validation – Use smart controls where feasible

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Possible Solutions Design is driven by IDE code generation – Resist the temptation to insert code into an the UI just because the IDE makes it easy. – Explore the limits of your tools – Where possible, split the code into two parts

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Possible Solutions Technical issues of the platform – Learn your platform and language thoroughly – Explore key aspects needed for testing UI Event generation and capture Instantiation of UI elements as part of a test Access to contained UI elements – Be clear on what testing is needed

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved The “Hardness” Paradox Perhaps “hard to test” is a good thing… – Most of the problems that make GUI testing “hard” are problems of design – “Hardness” can be a signal to look more deeply at how our application is designed – Question: Are ALL such problems signals of design issues? How can we tell?

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved The Message Some of the lower-level techniques require platform-specific knowledge, even though similar things must be accomplished on every platform.

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved The “Hardness” Paradox Perhaps “hard to test” is a good thing… – Most of the problems that make GUI testing “hard” are problems of design – “Hardness” can be a signal to look more deeply at how our application is designed – Question: Are ALL such problems signals of design issues? How can we tell?

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Yes, because… Testability is just as valid an objective as security, safety, ease of deployment or any other desirable characteristic Poor testability is almost always due to other problems in the design, particularly poor separation of responsibilities, and excessive coupling between components.

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Principles Know exactly what you’re testing – Each test should have one purpose – Do you really need to test it? Too simple to fail Part of the platform

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Principles Keep domain logic out of the UI – Use separate domain objects – Test them separately, without the UI – Make the UI as thin as possible – Consider NOT testing it!

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Principles Avoid tight coupling with the domain – Use creational patterns that allow substitution – UI should not create domain objects directly – Use interfaces in languages that require them – Mock the domain when testing the UI

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Principles Apply separation of concerns to the UI – Separate behavior from display – Use separate classes for validation – Use smart controls judiciously

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Principles Avoid code generation pitfalls – Resist the temptation to insert code into an the UI just because the IDE makes it easy. – Explore the limits of your tools – Where possible, split the code into two parts

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Principles Learn your platform and language thoroughly – Explore key aspects needed for testing UI Event generation and capture Instantiation of UI elements as part of a test Access to contained UI elements – Be clear on what testing is needed

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Principles Understand your own common mistakes – Don’t test getters and setters… unless you habitually mess them up – Don’t test whether event’s are hooked up… unless you often forget to hook them up

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Background The NUnit test framework allows users to assign tests to categories and run all the tests in one or more of these categories. A domain object maintains a list of all the available categories and another list of the currently selected categories. The UI must display the available categories and allow users to select those to be used in a run.

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved The Model Categories are represented by strings. The available and selected category lists are represented as arrays of strings. Initially, the available category list is hard-coded. The following methods are provided: GetAvailableCategories() GetSelectedCategories() SetSelectedCategories()

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved MVP Presenter View Model View delegates event handling to Presenter. This is the classic implementation. Also called HumbleDialog.

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Further Tasks Modify SimpleGui to use MVP Add Event Handling to Model Support changing available list asynchronously Make gui richer: add second list box and Add and Remove buttons.

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Three Rules of UI Testing Get business functions out of the UI – Use domain or controller objects – Test them separately Get UI logic out of the Form – Separate controller objects – Derived or User Controls – Test them separately Know what you’re testing for – Do you really need to test it?

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Non-Essentials Things that are usually non-essential – Precise positioning of controls – Shades of color – Exact sizes They become essential – When they are hard requirements – When code depends on them

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved Testing Event Handling Test Generation of Events – Use a mock or fake to capture the events Test Handling of Events – Use a fake to send the events

Test Driven User Interfaces Copyright © 2005 Charlie Poole. All rights reserved UI Testing Approaches Testing through the GUI Testing immediately “under the glass” Isolated GUI testing Exploratory testing Visual TDD

Copyright © 2005 Charlie Poole. All rights reserved Test First User Interfaces XP2005 Sheffield University June 18, 2005.

Similar presentations

Presentation on theme: "Copyright © 2005 Charlie Poole. All rights reserved Test First User Interfaces XP2005 Sheffield University June 18, 2005."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Copyright © 2005 Charlie Poole. All rights reserved Test First User Interfaces XP2005 Sheffield University June 18, 2005.

Similar presentations

Presentation on theme: "Copyright © 2005 Charlie Poole. All rights reserved Test First User Interfaces XP2005 Sheffield University June 18, 2005."— Presentation transcript:

Similar presentations

About project

Feedback