Why Your Selenium Tests Are So Dang Brittle

If you are writing automated through-the-GUI tests for a web application, you are in danger of creating software 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.

In this webinar to learn:
– 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

Video Producer: Pillar Technology

1 Comment on Why Your Selenium Tests Are So Dang Brittle

  1. You are certainly right that writing selenium code, and doing more than simple recording takes a lot of thought and effort in order to make the code maintainable. The levels of abstraction and ‘lingos’ that you mention necessary for a robust object model are difficult to really make them maintainable. Thanks for posting this youtube video as we often have problems with this.

1 Trackbacks & Pingbacks

  1. Automated Testing Tools and Test Automation Brittleness | Automation Anywhere | How to avoid automated tests that fail more as time goes on

Comments are closed.