In the project that I am currently working in, we made some non conventional choises for testing and making sure that we build quality software. First of all we decided against unit testing as none of us was real practioner of TDD. Rather some of us even believed that TDD actually creates waste as in some cases tests can become a rigidity and liability for the project’s development forward. Instead we decided to put the efforts into functional testing – to test the actual user stories and features that end users use, rather than individual components that make up the software. As we are building a web application, natural tool to be used would be Selenium or something alike – in this case we used the ’alike’, namely Webdriver.

After using previously Selenium RemoteControl, Webdriver felt like a breeze of fresh air – no longer cumbersome configurations or setups, just launching webdriver based tests with FirefoxDriver and voila – Firefox pops up and your testcase drives firefox through your application like demons posessed it. It can be quite soothing and hypnotizing to look at computer surfing your web application – but it can be quite unproductive unless you have popcorn to eat or a book to read. If you are developing web applications, then WebDriver is something you should definitely take a look at!

Below is a small clip from a sample test of ours, it’s a JUnit 4 test.

// Setup function run before the test method is run
@Before
public void setupFriendsForTest() {
setupTestUsersForPrimaryTestUser(); // Sets up test environment and creates dummy testusers to be tested
}

Simple test above shows most of the most used features of WebDriver: commanding driver to load a page, finding elements from the page by classname or id – and clicking an element on the page. Method missing above is how to enter text into elements on webpage, which is described as an example below:

webElement.sendKeys("datasend to the element");

Looks simple and is quite easy to understand. But what do these tests mean for webapplications?

Well they give you a safetybelt and reassurance that the feature or features that you have built actually do work as they were supposed to work. The code above – as simple as it is – actually spotted a simple bug in frontend javascript code that manifested itself after some ui fixes and javascript refactoring. No unit test would have spotted this, as the backend worked flawlessly.

Functional tests also help webapplication creators to communicate and plan with customers how features work and are accepted. If functional tests are written first – atleast the first version, it can help programmers and designers to see flaws in their plans or thinking before they implement themselves into the corner. Walking through userstories and creating tests first actually forces you to think things through your end users point of view.

Sure it takes some time to get into the culture and practice of writing functional tests based on your user stories, but sooner or later you have done all the basework and have enough utility functions in your baseclasses that writing new tests for your application is a snap and comes as a routine. In our project my ultimate goal is to get to the point that ui-designers and concept planners are capable of writing and reading functional tests as well as programmers are – and have these functional tests as the most important tool to define confirmation ( acceptance criteria ) for our user stories and aid in our conversation.