Lawrence Song

I was working in a project which used Selenium RC as web test tool. The functional test coverage is high. However, as the application has become more complicated and more tests have been added, the automated testing becomes a bottleneck for velocity. The problems?

• Hard to understand the intent of automated tests
• Duplication of Selenium test code
• Hard to reuse
• Page objects has all responsibilities of page operations and verifications
• Test the wrong thing
• Because of complexity, fewer scenarios are created
• Overtesting cause performance problem
• New team members find it hard to write tests
• QAs take a long time to write automated tests

Let’s see how to solve all the problems listed above.

In the project, developers and QAs are both writing selenium tests. Without navigator into the code, it’s very hard to understand what does the particular test do.One way to solve the problem is to name the test better. for example testShouldAllTestFieldSetMaxLengthAsWhatTheyExpected(). However, selenium tests is not unit test, sometime it’s not easy to give a name to define all the operations and verification of the tests.

Recently, DSL became a hot topic. Define DSL in automated tests would help develops and QAs (even BAs) understanding the intent of all tests. Hence, I decide to define DSL for elements in the page object.

The advantage to use DSL as following:

• Easier to read
• Precise error message, i.e.:
  • assertTrue(selenium.isElementPresent(”id”) will give you message”expect true, but false”, what the heck does that mean when you see the error message?
  • element.shouldExist() will give you message “expect element ### exist, but not exist”, you can customized the error message you want.
• Reuse DSL
• No more asserts in the test class
• Quicker development
• Precise testing

Here I show some simple DSL. (two types: operations and verifications)

TextBox:

• type(String text)
• shouldDisplayRedBorder(), shouldNotDisplayRedBoder()
• shouldDisplayValue(String expectValue)
• shouldBeReadOnly(), shouldNotBeReadOnly()
• shouldBeDisabled(), shouldNotBeDisabled()
• shouldExist(), shouldNotExist()
• ……

Radio:

• click()
• shouldBeSelected(), shouldNotBeSelected()
• ……

DropDownList:

• selectLabel(String label)
• sleectIndex(String index)
• shouldDisplayLabel(String expectedLabel)
• shouldDisplayIndex(int index)

Checkbox, Label, ErrorIcon, Table…

Depends on the project, you can create more customized element suitable for your need.

In page objects, we just need to return element object. for example:

class AmazonPage

public searchInDropDownList() { return newDropDownList("url"); }

public fieldKeywordTextbox() { return newTextbox("field-keyword"); }

public searchButton() { return newButton("go"); }

}

then the test become look like

amazonPage.searchInDropDownList().selectLabel("Books");

amazonPage.fieldKeywordTextbox().type("Selenium");

amazonPage.searchButton().click()

self-documentation is better than having a lot of comment in the test.

In selenium DSL II, I will talk about how to define better DSL syntax.