On our latest project, My colleague Tjeerd Kaastra and I, have been using Wicket.
Since our GUI was so complex, and we had to write 100s of unit tests (a lot of corner cases), we sat down with our testers to find out how we should approach this. Because Our testers use Fitnesse to test both functional acceptance as well as regression tests, they test a lot of the code as well. So we thought, why not integrate the two and that is what we did.

This blog describes how to test Wicket applications using Fitnesse. It is about stretching the limits of the Wicket test components to do so. We will try to explain this by using a small example project we have created to illustrate things. This example project has been inspired on the new user wizard example by Eelco Hillenius. We adapted this example so that it uses Spring, because most apps use a backend system.

For those who don't know what Fitnesse is: FitNesse is a web server, a wiki, and a software testing tool. FitNesse allows users to enter specially formatted input (its format is accessible to non-programmers). This input is interpreted and tests are created automatically. So Fitnesse offers great options for automated testing beyond your unit tests. Wicket has got some utilities to unit test your application GUI outside a container. These components are org.apache.wicket.util.tester.WicketTester and specifically for Form components there is org.apache.wicket.util.tester.FormTester. Would it not be great if we could use these unit test components for functional testing in Fitnesse?

Forms can be tested using the FormTester. But unfortunately, the FormTester is meant to test one form and as usual in a unit test, you write a seperate testcase per scenario. From a functional point of view, you might want to test a form submit, then go back to the page, correct some validation issues and re-submit the form.
In real life, we used an abstract fixture class to provide all the generic methods and an extended fixture that gives us all the implementation details (like the correct application context, model class, start page, etc). The abstract fixture has for instance methods to check if components exist, set and select methods and lots more. See the example project.
Furthermore, throughout the code you will see several boolean return values that seem unused. This is a fitnesse best-practice. Whenever a boolean is returned, the Fitnesse test will color the result cell green or red so you can verify that the method was executed.

Testing the wizard
So for those who do not know the Wizard component, a wizard component is a dialog component that takes it's users through a number of predefined steps. It has common functionality like a next, previous, finish and cancel button, and it uses a transition rules to let clients navigate through it's steps.

Here's a typical fitnesse table that you might want to use to test your flow:

Look's easy enough, right? Well, there are quite some steps to take to achieve this easy testing scenario, and of course a couple of problems.

Problem 1: using field values instead of index numbers
Normally, using WicketTester you must define indexes for all fields that you want to test. When writing unit tests, this is not a problem but since we want to cater for functional testing, we will have to use reflection to achieve this.

We will not be going in to the ReflectionUtils, but the setFieldValueThroughSetMethod sets a value for a specific field through the corresponding Set method.
Since we tend to use ListView components for repeating form elements, we also added a special method to be able to add a value to a component at a certain position in the list that the ListView uses.

Problem 2: submitting multiple times and keeping you feedback
The actual submit has several problems to solve:
FormTester only allows one RequestCycle, meaning you can only submit a form once after which you must setup your testcase again. The formtester also does not update the model since it only tests one step.
Since the submit only tests the local step, we have to call .onSubmit() on the Next-button to proceed to the next step.
Feedback messages get lost if you submit a form using both FormTester and WicketTester. When you set a field value, store this value in a Map that will be used as a cache.

On submit, first retrieve the WebSession and remove all feedback messages.
Then set any field values that you have cached on the form again.
We then submit the FormTester to validate the form behavior and when all goes well (meaning there are no error messages caused by validating the form entries) we move to the next step.

Problem 3: ListViews do not get rendered automatically
Because you cannot update values on unrendered components, we will have to render our ListView components manually. Therefore, when moving to another step, we should render the components, see RenderComponents() in the Abstract Fixture.

Problem 4: Map values to Object attributes.
Because rendered values are Strings, for Example in our example application we have a User object which has a List of Role's, we only display the roleName of the Role object.
We need to be able to map an input string to an Object attribute.
So if in fitnesse we say

One of the nice things about a component-based framework is that your GUI components are backed by real Java objects. However, this makes it harder to test if a field is filled as expected. When setting up a fixture, we need to create a map of Object types and their corresponding GI fields.
Add this to your initialize method:
addTypeAndFieldName("Role", "roleName");
addCustomComponent("org.apache.wicket.markup.html.basic.Label");
addCustomComponent("org.apache.wicket.markup.html.list.ListView");

So lets illustrate a couple of tests.

Test 1:
- Check if the expected components exist on the NewUserWizardPage.

In your browser the page look like this:

The fitnesse test looks like this:

As you can see it is easy and readable. As you can see, our test is comform point 3. The testers do not need to fill in the Fully Qualified Name for RequiredTextField. To be able to do this, we keep an internal map of components fully qualified names. If you have Components that does not reside in the package org.apache.wicket.markup.html.form., you have to add them by adding a line like addCustomComponent("org.apache.wicket.markup.html.basic.Label"); to the initialize method in the fixture.)

Test 2:
- Press the "Next" button and check if there are any errors and if we are on the correct Step in the wizard.

In your browser the page look like this:

The fitnesse test looks like this:

Test 3:
- Fill in username and press the "Next" button and check if there are any errors and if we are on the correct Step in the wizard, then fill in email address and press the "Next" button and check if there are any errors and if we are on the correct Step in the wizard.

The fitnesse test looks like this:

These are just a few examples of how to test you wicket application using fitnesse.
As you can see, it make it very easy to test and it is readable!!

By combining the power of Fitnesse and Wicket , we are enabling non-techies to write automated tests. This way, your UI is tested completely in each iteration within a few hours, this gives us a major quality improvement and it really speeds up the testing (imagine how much time it would take to do a regression test by hand!). Our project proved the combination to be very valuable to both developers, testers and our customer.

The sources of the example project can be found here. Read the installation.txt file in the directory src/main/documents to get you started with the example app.

Filed under Ajax, Java, Spring, Testing, Wicket | 7 Comments »