Why to Use FitNesse or ATDD on Top of Selenium?

For Web Application development Selenium is a defacto tool for functional testing with its click and capture capability through browser plugin. At the end of recording, Selenium script can be converted in a test-case in almost any programming language.

Immediately after you begin talking about functional testing people jump on the tools and would like to know what tools you are using or going to use.

And in practice that’s how it works. Somebody will say let’s use Selenium and somebody else will come up with a suggestion to use Xebium or FitNium. In some projects which-tool-to-use becomes very clear within a day but unfortunately fewer understand the business-case of using Xebium or FitNium instead of pure Selenium.

This post tries to answer following questions:

• What’s the need to cover Selenium with FitNesse to begin with?
• In practice does FitNesse + Selenium work any better compared to pure Selenium, based on the reasons mentioned in last question?

Why Selenium + FitNesse (Xebium or FitNium)?

The basic idea of using FitNesse on top of Selenium is to enable a tester or a customer to start writing a functional test cases even before developers start coding. That’s a big advantage as testers then are able to utlise their time to do some worthwhile work at the beginning of the Sprint.

That way FitNesse test cases become the concrete acceptance criteria in front of developers too.

This is the basic fundamental idea of “ATDD”

Here is a screenshot of a Xebium (can convert FitNesse test case into Selenium script and vice-versa) test case:

Above test case is written in following pattern or DSL:

[bash]
start browser <browserName> onURL <url>

ensure do open on …
ensure do verifyTitle on …
ensure do verifyTextPresent on …

stop browser
[/bash]

The test case language is far simpler than any other technical test counterpart. As a result any tester can easily learn and write test cases using Fit framework. Even though the premise is to enable people without any technical know-how to write acceptance test cases, it doesn’t look that easy for a non-technical person by looking at the DSL and its essential grammar. It requires some learning curve and I am not sure if every non-technical person will be wiling to write a test case using FitNesse based DSL.

Better choices for Selenium + ATDD

In my last blog “Distributed Agile: Acceptance Test Driven Development (ATDD) in Practice” I talked about ATDD in practice for Distributed Agile teams using “Behavior Driven Development (BDD)” frameworks like “easyb”. Tester/customer write the test cases in pure English based DSL and developer and tester then fill the implementation of the test case.

Here is an “easyb” scenario which a customer/tester writes and you see how easy it’s to write and explain:

[groovy]
scenario "User submits valid credentials and gets to the home page",{
given "Open the login page",{
}
when "User enters valid credentials and submits", {
}
then "Album List specific to the user is shown to the user", {
}
}
[/groovy]

As I said implementation has to be written by a developer, here’s a Selenium implementation in Grails, using Page Object Pattern,

[groovy]
def loginPage
def homePage
scenario "User submits valid credentials and gets to the home page",{
given "Open the login page",{
loginPage = LoginPage.open()
}
when "User enters valid credentials and submits", {
loginPage.username ="john"
loginPage.password = "pass1"
homePage = loginPage.submit()
}
then "Album List specific to the user is shown to the user", {
homePage.verifyPage()
}
}
[/groovy]

Conclusion

We can use BDD based frameworks to our advantage to write Selenium test cases in ATDD fashion which brings a big change the way acceptance test cases are written and executed. Also in practice, it’s much-much easier to get some direct interaction of PO with the application without being too verbose.