There are many products for automated testing optimization presented by Selenium: RC, GRID, IDE, WebDriver.  To my mind, the most interesting is the last one - Selenium WebDriver (SWD). Let’s take a closer look at it.

What is SWD?

SWD is a library providing an interface to emulate user’s actions in a browser, manage browser’s behavior for other software, manage data flow between a browser and these pieces of software.

SWD is being developed by Seleniumhq team and has bindings for many programming languages: Java, C#, Python, Ruby, JS, Objective-C and Perl.

There are no Php bindings developed by Seleniumhq team, but there is a couple of third-party bindings. The most recommended was developed by Adam Gouche.

SWD supports all mainstream browsers  Google Chrome, Mozilla Firefox, IE, Safari, Operа (3rd party) + mobile OS browsers (iPhone and Android). You can find more detailed information about browser support here.

SWD functionality

SWD has pretty rich API reference, so let’s stop at the most basic and interesting things.

• Get page by URL
• Locate element at the page (via css selectors/xpath)
• Forms interaction: fill textfield, file uploading, choose an item from selectbox, check the box, click the button etc.
• Execute JS code on the page
• Drag’n’Drop emulation
• Take a screenshot
• Cookies management

SWD also has functionality helping to test ajax-based web-applications. SWD has two kinds of waiting functions: implicit wait (wait for given amount of time and then continue execution) and explicit wait (SWD waits for certain conditions to be fulfilled, e.g., some element should appear/disappear from the page). This functionality allows us to write tests for ajax-based applications in an agile manner.

It is a small part of functionality the SWD has.

By the way, SWD is not a test library. So, you have to add some test library to your project to write a test using the SWD. It could be JUnit, NUnit, PHPUnit etc. See a full list here.

Let’s test some examples.

SWD-based testing framework

We need to have some web-application/custom web application, website, SWD, testing library and some IDE.

All the examples were written using SWD’s Java binding, JUnit, and Eclipse. The test set and all other files needed for test execution are being stored at the bitbucket repository.

SWD has rich functionality, but it is kind of rough.  So, it is widely spread practice among the developers to write separate testing framework wrapping the SWD library for the given project. For example, SWD has a click function and wait for function, but it has no clickAndWait function which is very useful. All pros of this approach are obvious:

• easy scalability
• every member of the team works with the same set of tests
• independence from the SWD core changes

SWD tests in Drupal

Drupal is an actively developing system, so SWD didn’t simply pass it by. There is a module called Selenium utilizing SWD functionality. It has several advantages:

• test structure and syntax are mostly the same as core Simpletest module has, so developers who dealt with writing Simpletest’s tests will learn the new things fast
• tests written using this module are running as a Drupal native test through Configure->Development->Testing-> Run tests
• allows test JS

This module implements DrupalSeleniumWebTestCase class which extends DrupalWebTestCase class of the Simpletest module. SeleniumWebDriver and SeleniumWebElement (analogs of the native SWD lib classes) are also implemented. To get this module’s test working you should have Selenium Server enabled. All the interactions between tests and Selenium Server are going through cURL requests.

Conclusion

So, we saw, that the SWD is a powerful tool drastically saving time and efforts of the team members. It allows testing some typical functionality (including ajax) with pre-defined behavior. This tool can be used to write agile automatic tests and can simplify the regression testing process.