HippoCMS 7 integration testing with Selenium
Integration tests are designed to check the functionality of an application as a whole, rather than focussing on the internal workings of individual software modules, which is the domain of normal unit testing.
Selenium
Selenium is such a toolkit to create and run automated integration tests. In our latest sprint (M11) we've used it to implemented a few simple test-cases.
* log in and out with different users
* perform some simple document editing
* create a new user and check if it is able to login
Creating new tests
New tests can be created using the Selenium IDE plugin (Firefox only); simply open HippoCMS 7 in Firefox, start test-recording in Selenium IDE and follow your test-script. These tests can than be replayed during integration-testing using the Selenium Remote Control, which takes care of creating a new Firefox instance, running the tests and shutting Firefox down again.
Stable markup ids
For Selenium to identify which DOM-element should be clicked or which text-field should be edited, it depends heavily on the id attribute of DOM-elements. This makes the presence of stable markup ids a must, meaning that a test should always be run with the same HTML as when it was recorded, or else it will fail for the wrong reasons.
Wicket however, and therefore HippoCMS 7, generates markup ids on the fly for Wicket components meaning they will differ from request to request, making them unsuitable for identifying a component in the browser DOM. To work around this problem Berry van Halderen wrote a patch that modifies the Wicket core in order to make it generate stable markup ids.
Handling Ajax requests
As a first attempt of handling Ajax requests, we've implemented a rather blunt approach: after sending an Ajax request, test for n seconds if a condition is met, like isTextPresent('Welcome to Hippo CMS'), else fail. In next sprints this will change by integrating Selenium with Wicket-Ajax and making it possible for WicketAjax to notify Selenium when a request has been handled.
Running the tests
We currently run our tests using the Apache Geronimo selenium-maven-plugin which deploys the quickstart-ear into Glassfish, starts Selenium, runs the tests, stop Selenium and undeploys the ear.
To get a better feeling of how this works out you can check out this video Arje Cahn made:
Use case testing with Selenium from Arje Cahn on Vimeo.
More info
If you like to run the tests on your local machine or create some yourself, be sure to read more on the documentation page once it is online.