Recent dabbling with Selenium has been great fun, and has shown me that there is a quick way of doing selenium testing, and a not-so-quick way. The quick way (which I shall call the path to the dark side) is to use the Selenium IDE plugin for Firefox, and simply record what you do on a web page. Then play it back in the IDE, or export it to Java / JUnit.
The slower way is to hand-code the tests, using Eclipse (or <insert tool of choice>) and making the tests truly your own. This takes a bit longer, and can be a bit slow at the start, especially while setting your code framework up.
So which way to choose?
Well, while I was learning, I loved the Selenium IDE. Quick results, tests running! Fantastic. Then I started realising all the things that could go wrong. For example, if you have 20 tests all written "longhand" - i.e. step-by-step, direct-access to each control on each screen... then this is ok until somebody changes the content of one of the screens. At this point... you have to go in and modify each test script, and believe me - they can get very long and unreadable.
So I wanted to avoid the dark side. Cue Page Object Models, and abstraction from the page content.
The Page Object Models (POMs) in Selenium let me say "this is my login screen, I have these fields.". I can write framework methods which allow me to provide lots of powerful processes to my tests. For example... on a Login screen, I could write a test that looks like this:
Find the username field.
Clear the username field.
Type in "validusername".
Find the password field.
Clear the password field.
Type in "validpassword".
Find the <Login> button.
Click the <Login> button....
You get the idea.
Now if we were using a POM for the Login screen, we could add 2 helper functions, say
loginWithCredentials(username, password)
isValidationErrorShown()
These functions would have direct access to the username field, password field and <Login> button, and would handle all the manipulation for the caller.
So we could then write our tests like this:
// Test 1: Non-existent user
loginWithCredentials(nonexistentuser, password)
assertTrue(isValidationErrorShown)
// Test 2: Valid user, invalid password
loginWithCredentials(validuser, invalidpassword)
assertTrue(isValidationErrorShown)
// Test 3: Valid user, valid password
loginWithCredentials(validuser, validpassword)
assertFalse(isValidationErrorShown)
These tests are very quick / simple to write, very simple to read, and very simple to maintain.
If the ID of the username field changed - the dark-side coding would now require all tests to be updated. The POM-based code... just change the POM function, and all the higher-level tests remain totally unaffected. Simples.
It may take a bit more initially to set up your POMs, but they are the only way to go when coding properly.
Don't get me wrong - Selenium IDE is great to give you an understanding of a page, and give you an understanding of what you're trying to achieve. But long term... invest in your code, and reap the benefits.
May the Selenium Force be with you.
The Selenium IDE plugin for Firefox can be downloaded from:
Eclipse can be downloaded from:
For a sample project using a POM (to illustrate this topic), please see the tutorial article here:
