Testing, testing – Testing webapplications with WebDriver

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
public void setupFriendsForTest() {
setupTestUsersForPrimaryTestUser(); // Sets up test environment and creates dummy testusers to be tested

public void cleanupTestUserFriends() {
cleanUpOldTestUsers(); // Cleans up the test environment

public void testFriendsListOnHomePage() throws InterruptedException {
loginPrimaryTestUser(); // Common utility method that logs our testuser in
driver.get(testBaseUrl + "/home/friends"); // Goes to the url we want to test

Thread.sleep(500); // Wait for ajax-operations to finish. This is silly way to handle the situation, but works for this sample

// Check that there are 6 friend elements on page
List friends = driver.findElements(By
.className("vcard friend")); // Get a list of elements from the page
assertEquals(6, friends.size());

int friendsListSize = 6;

// Loop through friend list and remove friends one by one
while (friendsListSize > 0) {
final WebElement friend = friends.get(0);
removeFriend(friend); // Call the method that is defined below
friends = driver.findElements(By.className("vcard friend")); // Get elements again
assertEquals(friendsListSize, friends.size()); // Check that one user was removed

private void removeFriend(final WebElement friend)
throws InterruptedException {

final WebElement removeButton = friend.findElement(By
.className("remove")); // Get remove button

Thread.sleep(500); // Wait for ajax operation to finish and open a dialog

final WebElement removeFriendBlock = driver.findElement(By
.id("removefriend")); // Get the dialog element

final WebElement removeFriendButton = removeFriendBlock.findElement(By
.id("removefriend-remove")); // Find a remove button inside the dialog

Thread.sleep(1000); // Wait for the dialog to fade away and close

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.

This entry was posted in Uncategorized. Bookmark the permalink.


Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:


Olet kommentoimassa WordPress.com -tilin nimissä. Log Out / Muuta )


Olet kommentoimassa Twitter -tilin nimissä. Log Out / Muuta )


Olet kommentoimassa Facebook -tilin nimissä. Log Out / Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out / Muuta )

Muodostetaan yhteyttä palveluun %s