This document discusses strategies for making Selenium web application GUI tests less brittle. It recommends writing fewer GUI tests and more unit and integration tests. For the GUI tests that are written, it suggests hand coding the tests in Java rather than recording and playback, using object oriented design principles, keeping test framework code dry while allowing test code to be wetter, and using element locators like ID attributes and xpath as a last resort. The document then provides examples of code that implements these strategies.

1. Why Your Se Tests are
So Dang Brittle…
…and what to do about it
Patrick Wilson-Welsh
pwelsh@pillartechnology.com

2. Introduction
Patrick Welsh
Senior Agile Consultant
Pillar Technology Group
http://pillartechnology.com
pwelsh@pillartechnology.com
http://patrickwilsonwelsh.com
http://coderetreat.ning.com/
mobile: 248 565 6130
twitter: patrickwelsh

3. Caveat Lector:
This is a technical webinar.
To follow, you’ll need to know Selenium,
a bit of Java, xpath, HTML,
and a bit of Object Oriented Design.
And, I will be gentle. 

4. We‟re here to help …

5. How hard is it to regression test an entire
enterprise web app using any web-app-
GUI-black-box testing tool?

6. too hard

7. Number #1 Reason Selenium RC, through
the web app GUI tests are so brittle?

8. Because you are writing
too many of them.
Let me put that another way.

9. You are committing too high a percentage
of total test-automation and
programming resources to
that specific kind
of automated testing.
Have a plan for outgrowing that pattern.
Actually, have a fairy tale:

10. 3 kinds of automated tests

11. GUI
end-2-end,
integration, story,
acceptance
unit/micro/isolation

12. TCO
% of automated testing work

13. good:
least
investment/ROI
good:
most
investment/ROI

14. least rework & waste; lowest TCO

15. But that’s not your triangle, yet.

16. we often start here

17. good:
easy to learn
bad:
hard to learn
for good reason!

18. bad:
high TCO,
low ROI
good:
low TCO,
high ROI
But again, the price

19. So, you’re stuck with more Se testing than
you should be doing. That’s ok. So am I.

20. How can we minimize the brittleness of
these inherently brittle tests?

21. Following are things that help me
and my teams.

22. Don‟t tell me testing is “not your job”

23. Automated testing is everybody’s job.
Se tests are written by testers and
programmers together. Period.
The whole team shares sufficient testing as
part of Definition of Done.

24. • Use Se only for what it‟s good for
• Never record and play back tests
• Se IDE is just a sandbox. Not an IDE.
• Hand-roll your tests (I use Java)
• Use a bit of Object Oriented Design
• Separate test code from framework code

25. • Test classes get common setup
• Keep test framework code really DRY
• Beware test code that is too DRY
• Duplication is built into GUI test code
• Test-class page flows: “open-coded”
• Don‟t fret so much about encapsulation.
• Concentrate on test clarity.

26. • Use id or name attributes if you got „em
• Use xpath as a last-resort element locator
• Use least-brittle xpath patterns
• Know the IE xpath pitfalls
• Beware of Firebug-Driven Development
• Use Singleton Se instance
• Use Singleton/static app state, carefully
• Consider a PageFlowSequence pattern

27. A principle to consider for Se testing:
DRY test framework; “wet” test code.

28. Let’s see some code already.

29. Q/A

30. Our Next Steps
• Upcoming Webinars: Please visit pillartechnology.com/events
• All of the webinar content is available to your business in a 1-2 day on-site workshop
or as a “lunch and learn” format. Please contact us for details.
• Visit www.pillartechnology.com/events to access presentation slides and full archived
broadcasts of past webinars.
• Twitter.com/agilesoftware
• Blog: www.pillartechnology.com/blog
• LinkedIn: Join the Agile Enthusiast Group on LinkedIn: http://bit.ly/agilegroup
• YouTube: http://www.youtube.com/user/PillarTechnology
• Phone: (888) 3-pillar
• Web: pillartechnology.com
• Email: info@pillartechnology.com