Every software developer very well knows that producing new code leads to producing new bugs (problems in the software).
The good software developers know that writing tests for their code doesn"t solve completely the problem but at least prevents regressions. Unfortunately developers often do not have time to write the tests, or are too lazy to do it, or just don"t like the way they do it and try to postpone it.
In this article I"ll describe a prototype of a mini framework that can be used to create functional tests for web applications that run blazing fast, are easy to debug and more imporatantly are very close to the real way a web application is being used.
Note: this article is not Wicket specific. The described solution can be used for any kind of web application.
A well known library for writing functional tests for web applications is WebDriver/Selenium2.
My problem with it is that it is:
- unreliable - every Driver implementation behaves differently. For me only FirefoxDriver works well
- well, let"s not say more bad words for WebDriver. Some of its developers may have the same opinion for Apache Wicket :-)
Apache Wicket project already uses QUnit for its unit tests since version 6.0.0 and so far they seems to serve us very well.
The main idea is that the tests run the application in an iframe, i.e. each test tells the iframe what is its initial source url, then the test can enter data in input fields, click links and buttons and finally assert the result of the previous actions.
The first problem is Cross origin requests - the tests need to be in the same domain as the application to be able to manipulate it.
There are (at least) two possible solutions:
- run the application with the proper Access-Control-Allow-Origin header value
- create a new application that merges the tests in the original application
The first approach is too obtrusive. It makes the application aware of its clients (the tests).
I prefer the second solution - by using Maven War Overlays we can create a Maven project that contains the tests and injects the original application in itself. This way the tests are available in my-tests folder in the web context for example.
To create QUnit tests you need to start with their HTML template. For our functional tests we need to put our additional iframe in its body. It is good to make the iframe big enough to be able to see what happens when you debug a test. In non-debug mode everything happens so fast that you cannot see anything ;-)
Here is the HTML template:
The interesting things here are:
- we preserve current page"s (the tests" page) jQuery in $q variable and unset the original jQuery and $ variables just to avoid name clashes later in our tests.
- we add Helpers.js which is a set of helper functions which are used by all our tests
- we add <script> for all actual tests
- and finally we add the iframe that will run the application
And here is how the tests themselves look like:
The idea is that we use QUnit asyncronous tests because often our tests will need to go over several pages in the application and we should not allow QUnit to go to the next test before the current test is finished.
So what does this test do ?
It registers a callback for the load event for the iframe and tells the iframe to go to the page we need to test. When the callback fires we make our assertions and then notify QUnit that we are ready with QUnit#start(). We can register several nested onPageLoad callbacks if the test needs to go over several pages.
The Ajax tests work similarly just they listen for Wicket"s Global . See ajax/form.js from the demo application for example.
A demo application that integrates wicket-examples.war can be found at my GitHub account.
To run it:
- git clone email@example.com:martin-g/blogs.git
- mvn install
- cd functional-qunit
- mvn jetty:run
- in a browser open http://localhost:8080/js-test/all.html
The tests can be integrated in Continious Integration setup easily by using PhantomJS and/or Grunt.js (also based on PhantomJS).
To run the tests with Grunt.js check the header content of grunt.js in the project.
The original idea is borrowed from User interfaces and unit testing with QUnit