Why Your Se Tests are
        So Dang Brittle…
          …and what to do about it

Patrick Wilson-Welsh
pwelsh@pillartechn...
Introduction

               Patrick Welsh
               Senior Agile Consultant
               Pillar Technology Group
 ...
Caveat Lector:

        This is a technical webinar.
To follow, you’ll need to know Selenium,
        a bit of Java, xpath...
We‟re here to help …
How hard is it to regression test an entire
enterprise web app using any web-app-
      GUI-black-box testing tool?
too hard
Number #1 Reason Selenium RC, through
  the web app GUI tests are so brittle?
Because you are writing
    too many of them.

Let me put that another way.
You are committing too high a percentage
       of total test-automation and
        programming resources to
            ...
3 kinds of automated tests
GUI



        end-2-end,
 integration, story,
       acceptance


unit/micro/isolation
TCO




% of automated testing work
good:
     least
investment/ROI




     good:
     most
investment/ROI
least rework & waste; lowest TCO
But that’s not your triangle, yet.
we often start here
good:
                   easy to learn




                       bad:
                   hard to learn



for good reason!
bad:
                       high TCO,
                        low ROI




                         good:
                 ...
So, you’re stuck with more Se testing than
 you should be doing. That’s ok. So am I.
How can we minimize the brittleness of
    these inherently brittle tests?
Following are things that help me
         and my teams.
Don‟t tell me testing is “not your job”
Automated testing is everybody’s job.

    Se tests are written by testers and
     programmers together. Period.

The who...
• 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-rol...
• Test classes get common setup
• Keep test framework code really DRY
• Beware test code that is too DRY
• Duplication is ...
• Use id or name attributes if you got „em
• Use xpath as a last-resort element locator
• Use least-brittle xpath patterns...
A principle to consider for Se testing:

DRY test framework; “wet” test code.
Let’s see some code already.
Q/A
Our Next Steps

• Upcoming Webinars: Please visit pillartechnology.com/events
• All of the webinar content is available to...
Upcoming SlideShare
Loading in …5
×

Why Your Selenium Tests are so Dang Brittle, and What to Do About It

3,206 views

Published on

If you are writing automated through-the-GUI tests for a web application, you are in danger of creating tests that are more expensive to maintain than they are worth. With well-factored Selenium RC tests running in Junit or TestNG, you can keep your abstraction layers or "Lingos" -- small bounded bits of slang for discrete parts of the object model -- separate, thereby reducing the maintenance costs of your tests, and improving your sanity.

This presentation is from a technical track webinar on:

•How and why automated web app code gets so dang brittle
•Why the expressiveness, readability, and fluency of your test code is so important to its maintenance cost
•Some basic, useful OOD patterns for writing very expressive web app tests using Selenium RC, in Java and in C#/.NET
•Some useful OOD principles to guide your design decisions, like keeping modules small, the SRP, DRY, "Lingos", and "Lingual Design"
•Some OOD principles worth violating, frequently, when writing automated test code, because it's just very different from application code
•How and why to prefer element locators like Id and Value attributes to xPath; how to keep xPath least brittle
•An introduction to Domain Specific Languages (DSLs) built on top of Selenium RC, using FitNesse
•An introduction to "fluent" Selenium RC testing using Scala
Prerequisites include experience with Java or C#, and ideally some basic OOD familiarity (inheritance, composition, encapsulation, polymorphism).

To view or download a replay of the event (WMV format), which included live demonstrations, please visit: http://www.pillartechnology.com/content/webinardetail/id/16

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,206
On SlideShare
0
From Embeds
0
Number of Embeds
93
Actions
Shares
0
Downloads
53
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Why Your Selenium Tests are so Dang Brittle, and What to Do About It

  1. 1. Why Your Se Tests are So Dang Brittle… …and what to do about it Patrick Wilson-Welsh pwelsh@pillartechnology.com
  2. 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. 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. 4. We‟re here to help …
  5. 5. How hard is it to regression test an entire enterprise web app using any web-app- GUI-black-box testing tool?
  6. 6. too hard
  7. 7. Number #1 Reason Selenium RC, through the web app GUI tests are so brittle?
  8. 8. Because you are writing too many of them. Let me put that another way.
  9. 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. 10. 3 kinds of automated tests
  11. 11. GUI end-2-end, integration, story, acceptance unit/micro/isolation
  12. 12. TCO % of automated testing work
  13. 13. good: least investment/ROI good: most investment/ROI
  14. 14. least rework & waste; lowest TCO
  15. 15. But that’s not your triangle, yet.
  16. 16. we often start here
  17. 17. good: easy to learn bad: hard to learn for good reason!
  18. 18. bad: high TCO, low ROI good: low TCO, high ROI But again, the price
  19. 19. So, you’re stuck with more Se testing than you should be doing. That’s ok. So am I.
  20. 20. How can we minimize the brittleness of these inherently brittle tests?
  21. 21. Following are things that help me and my teams.
  22. 22. Don‟t tell me testing is “not your job”
  23. 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. 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. 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. 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. 27. A principle to consider for Se testing: DRY test framework; “wet” test code.
  28. 28. Let’s see some code already.
  29. 29. Q/A
  30. 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

×