Automating Form Testing with Selenium IDE

Testing Forms

Automating the testing of forms helps speed up the test process and saves having to do the repetitive work of filling the form with test data.

We use Selenium IDE for our form testing because it is simple to use and is integrated into Firefox.

Selenium IDE

Test Suite

With the redesign of our enhanced listing signup form we needed to rewrite our selenium test suite for testing the signup form.

Using selenium IDE we can record our actions in the browser and replay them so we can step through every test and check the form works as expected.

If you have used unit testing before selenium and its concepts will be familiar to you, with selenium the tester can assert things such as checking for error strings in the form when the form has been submitted or asserting a page has the desired title or heading.

We first start by testing the form to make sure that our error checking is working we like to test all the required fields in a form and stepping through each required for field and asserting the error string is present in the form.

Then we move through the form testing any other constraints such as passwords not matching and finally check the form with correct data to verify it works correctly.

Recording your browser is as simple as clicking the record button in the UI and then carry on as usual, you can also access rules and statements by right click your mouse or adding them directly from the IDE GUI.

Conclusion

When you need to test a form using selenium to drive it makes sense and it saves time and effort when rerunning any tests. We like to use test driven development to help improve the standard of our code base.

Very soon we will be moving The Care Homes Directory over to using a pure div layout for the whole website in an attempt to improve keyboard navigation of our website for improved accessibility for non mouse using visitors.

And releasing a new improved enhanced listings sign up form and Google wallet payment support which greatly improves the users experience.

Also we are adding aria data to our website and are improving our <nav> structure so we can improve our breadcrumbs.

PHPUnit and Test Driven Development

More PHP Testing

We though we would write another article this time discussing testing PHP scripts using PHPUnit in an attempt to produce quality test units from our test cases.

During development we write PHPUnit test cases for each class we implement this allows us to build a collection of tests which we can run if we make any changes to our code base.

This allows us to verify that any changes we have made to a part of the system does not affect it as a whole.

Software Testing

Installing PHPUnit

It is simple to install PHPUnit and there are a couple of ways you can go about it we use the pear packages provided for our installation. Run the following commands as root to start the installation process.

root@chic:~# pear channel-discover pear.phpunit.de &&\
pear install phpunit/PHPUnit

This will install PHPUnit on you system by adding the correct channel and running pear install. Pear is a great tool for packaging up PHP scripts but its beyond the scope of this article.

We also need to consider any dependencies which we need to install for some added functionality such as code coverage reports.

root@chic:~# pear config-set auto_discover 1 &&\
pear install phpunit/DbUnit &&\
pear install phpunit/PHP_Invoker &&\
pear install phpunit/PHPUnit_Selenium

Next we need to install xDebug which is a very useful and feature rich program which can be used for debugging purposes or profiling a script and much more.

root@chic:~# pecl install xdebug

Once this has installed we need to make the module load by adding a file to the conf.d directory under the PHP configuration directory.

/etc/php5/conf.d/

And add the following line to the new extension file like below by using a conf.d file allows changes to the main configuration to not affect xDebug,

zend_extension="/usr/local/php/modules/xdebug.so"

Now we are ready to start writing our test cases to build a test suit for any software we have developed.

PHPUnit

Writing Test Cases

When we write classes or add some additional functionality to existing code we make sure that we write a comprehensive test case which tries to test all available code paths.

During development of our news system we have been writing test cases after we complete  each class that implements our functionality.

We follow a kind of test driven agile development but we like to implement our test cases after we have written the class to be tested not the other way around. This is a slight variation on test driven development and one that suites us.

Our test case uses the usual naming convention for class names such as NewsFunctionTests would be the test case for the NewsFunction class this is used for all classes.

Test case files are located under the tests directory which is a sub directory of the location of the class file which is being tested.

When writing a test case our test class extends the PHPUnit_Framework_TestCase as you may have noticed phpunit makes good use of class name spaces so we should have no class name collisions.

Naming of our test methods follow the standard convention (although this can be configured via comment tags) of prefixing all tests with the string test so if it was to test a method called newsMethod() it would be called testNewsMethod().

PHPUnit will run any methods with a test prefix as a test and the results of those tests will be displayed to the user via the command line.

class NewsTest extends PHPUnit_Framework_TestCase {
  public function testNewsMethod () {
    $this->assertTrue(true);
  }
}

The documentation for PHPUnit has a whole section for explaining available assertions which are the basis of your tests this allows a developer to test a response is correct and as expected. Please see here for documentation on assertions.

We have found the PHPUnit documentation a good reference point for when we are writing tests and it is a very useful and comprehensive website.

Test Case Class

Using PHPUnit

For running tests we use the phpunit command line program we have organised our test cases using a directory structure we also write a config file for each test suite the config file is named phpunit.xml and when you run phpunit via the command line it will check the working directory for this file.

We create a config file for each suite of tests so our first task before running our tests was to edit the xml configuration file.

vi /web/root/tests/phpunit.xml

We add our config

<?xml version="1.0" encoding="utf-8" ?>
<phpunit>
  <testsuites>
    <testsuite name="example_tests">
      <file>TestCaseOne.php</file>
      <file>TestCaseTwo.php</file>
    </testsuite>
  </testsuites>
</phpunit>

After this we run our test suite using the command line application we have added some switches to control how the program is run. We generate a code coverage report when running our test suites as well as some agile documentation.

root@chic:~# phpunit --coverage-html /report/output/dir/ \
--testdox-html /report/output/dir/ \
--bootstrap /path/to/bootstrap.php

You may notice the bootstrap flag which allows us to execute the contents of the bootstrap file before testing starts. We use this to load our database abstraction layer and set some configuration data.

Once the program finishes running the tests will have been executed and the results of those tests will be displayed to the command line. It shows how many tests have been run and the number of assertions.

Any failures will be displayed to the command line along with some useful debug information to tell you what has gone wrong and what was expected and what was encountered.

PHPUnit Command Line

Code Coverage Reports

We generate HTML code coverage reports while running our unit tests so we can see which lines of code our tests cover and which lines it does not.

This allows you to know you are testing every last line of your classes we upload our code coverage reports using scp to docs.chic.uk.net which is our digest protected documentation site.

By studying the code coverage reports we can check any missing tests and make sure we are testing our whole code base and where to focus our testing efforts.

Code Coverage

Conclusion

Writing test suites to provide regression testing allows a developer to have confidence that their changes do not have wider implications on the system as a whole. We have found a combination of PHPUnit and xDebug provides us with a powerful testing platform.

Again this article show how we have taken advantage of an open source stack to provide a platform from which we can test our software.

In the coming weeks we will be writing an article regarding using xDebug for profiling scripts and using Kcachegrind to interpret the results from these tests.

Profiling allows a developer to focus his attentions on certain parts of code which may allow better optimisation in turn improving performance.

Finally a little note about our new feature to provide local amenity information we now have over 38000 local businesses in our database and listed on our listings pages and it is still growing.

This is a great resource for our visitors and we are happy with its progress so far please take a moment to visit one of our enhanced listings on The Care Homes Directory.

Appendix

PHPUnit logo: http://clivemind.com/wp-content/uploads/2012/07/logo.png
xDebug screen shot: http://webmozarts.com/wp-content/uploads/2009/04/xdebug_trace.png

Test class image: http://www.php-maven.org/branches/2.0-SNAPSHOT/images/tut/eclipse/phpunit_testcase.jpg