copyright © 2005 charlie poole. all rights reserved test first user interfaces xp2005 sheffield...

Copyright © 2005 Charlie Poole. All rights reserved

Test First User InterfacesTest First User Interfaces

XP2005

Sheffield University

June 18, 2005


Test Driven User Interfaces

ScheduleSchedule

2:00-3:00 IntroductionReview of Testing PracticesIs UI Testing Hard?Message of this Course

3:00 Break

3:15-4:15 PrinciplesPatternsPractices

4:15 Break

4:30-5:30 ToolsTechniquesConclusion



IntroductionIntroduction



Some Some BackgroundBackgroundAbout MeAbout Me



ContactContact Email

[email protected] [email protected]

Web Sites www.charliepoole.org www.pooleconsulting.com

Seattle XP Users Group www.seattlexp.org

NUnit Testing Framework www.nunit.org



Why Are We Here?Why Are We Here?

What sort of UI work do you do?What platforms do you use?What do you want from this course?



Testing PracticesTesting Practices



Agile DevelopmentAgile 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.



Tests in XPTests in XP

Acceptance/Customer Tests– Tied to Requirements– Express customer intention

Unit/Programmer Tests– Small units of functionality tested in isolation– Express programmer intention



Tests as CommunicationTests 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



Tests Communicate IntentTests Communicate Intent

From the customer– What the application should do

From the developer– How the application will do it



Test-Driven DevelopmentTest-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



The Circle of CodeThe Circle of Code

Simple Design Test-Driven Development

Refactoring

Continuous Integration



Effect of Continuous TestingEffect 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.



Automating TestsAutomating 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.



Is UI Testing Hard?Is UI Testing Hard?



ExerciseExercise

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.



DiscussionDiscussion



What Makes Testing Hard?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



Problems of GUI TestingProblems 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 generationTechnical issues of the platform



Possible SolutionsPossible 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




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




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




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



The “Hardness” ParadoxThe “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?



The MessageThe Message




GUI testing may be hard, but it’s no harder than many other aspects of

delivering great software.




What initially presents as a testing problem usually turns out to be a

design problem.




The design techniques we use to solve GUI testing problems are the same ones we use for business objects.




GUI testing presents unique technical – as opposed to conceptual – issues.




The general principles used for GUI testing are platform-independent.




Some of the lower-level techniques require platform-specific knowledge, even though similar things must be accomplished on every platform.



The “Hardness” ParadoxThe “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?



An Objection?An Objection?

Should we be modifying the design merely to make the

software easier to test?



Yes, because…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.



Questions?Questions?



PrinciplesPrinciples




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




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!




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




Apply separation of concerns to the UI– Separate behavior from display– Use separate classes for validation– Use smart controls judiciously




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




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




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



Simple GUI ExampleSimple GUI Example



BackgroundBackground

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.



The ModelThe 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()



Simple GUISimple GUI



DemonstrationDemonstration



PatternsPatterns



Model-ViewModel-View

ViewModel



MVCMVC

View

Controller

Model



MVPMVP

Presenter

View

Model

With no dynamic features, View can remain ignorant of both

Presenter and Model.



MVPMVP

Presenter

View

Model

View delegates event handling to Presenter. This is the classic implementation. Also called

HumbleDialog.



Extended GUI ExampleExtended GUI Example



Further TasksFurther Tasks

Modify SimpleGui to use MVPAdd Event Handling to ModelSupport changing available list

asynchronouslyMake gui richer: add second list box and

Add and Remove buttons.



Bits of AdviceBits of Advice



Three Rules of UI TestingThree 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?



Non-EssentialsNon-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



Specialized Test FrameworksSpecialized Test Frameworks

JFCUnitJWebUnitNUnitFormsNUnitAsp



Testing Event HandlingTesting 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



UI Testing ApproachesUI Testing Approaches

Testing through the GUITesting immediately “under the glass”Isolated GUI testingExploratory testingVisual TDD



ConclusionConclusion

copyright © 2005 charlie poole. all rights reserved test first user interfaces xp2005 sheffield...

Documents

charlie poole

test criteriawhoever

test criteriacopyright

continuous feedback

continuous integration

orgnunit testing frameworkwww

sort of ui work

failno code