Monday, 17 August 2009

Domain Specific Languages for Selenium tests

I've been doing some work lately creating automated functional test suites using Selenium RC to simulate user interaction with a web GUI. I discovered quickly that the tests you record directly from selenium are rather brittle, and hard to read. In order to make the tests more robust and readable, I have been extracting reusable chunks of script that make sense from the user perspective, into separate methods. For example when testing a page for registering a new provider, you might have a ProviderPage domain class, with method "createNewProvider". This method encapsulates all the selenium calls that interact with the page, and lets your test be written in terms of the domain.

I just saw this article from Patrick Wilson Welsh basically saying the same thing, only his DSL has three layers of indirection instead of just two. As well as encapsulating page operations in a Page class, he encapsulates operations on widgets within a page. I hadn't thought of doing that. It makes the code in the Page class more readable. I might try that, and see if it improves my code.

2 comments:

Anonymous said...

I just have to say that I think it's sad that Selenium still lacks an HTML Driver. When recording in the IDE, the HTML file it produces is normally not hard to understand (given you use some sort of useful id attribute values on your HTML tags), in fact, they're really straight forward and could be given to any monkey^Wtester as a manuscript. It can also map quite well to Use Case flows.
The major upside of using HTML as a Driver (instead of code in Java, python, ...) is that _I think_ testers/QA will be more open to contributing test cases, compared to checking in code into some SCM. Or just as a way to describe/reproduce bugs.

Emily Bache said...

I think testers/QA people who can't code have limited usefulness on an agile project. Maybe I'm writing tests that are too complex, but I would not like to maintain a bunch of tests written in HTML without the aid of refactoring tools, either. I think the best way to describe/reproduce bugs is to show them to the developer face to face, shortly after they are discovered.