Agile, Test

Agile testing

The vacation is over and a new project is just around the corner. As an iteration zero we have working on setting up the technical infrastructure and tried to carve out a test strategy for the development. In this project we really want to practice a test first strategy, not only for unit tests but also test driving the requirements. This means that before development of a feature can start, a set of acceptance tests should be written in a form that makes it executable. We’ve been using fitnesse (old style) for this for most of our previous projects. But it turns out that neither developers nor testers are particularty satisfied with the current solution. Developers thinks it is tedious and time consuming to develop and maintain tests investment. Testers too find it hard to use (for other reasons than developers, but that’s another story) and we find they often skip the regression tests suites because it is to hard to use.  If it is hard to use then people will avoid it.

So instead of continuing to use a process that is broken I thought that it would be a good idea to try to improve things a bit.  After talking with a few key people and some investigations we now use the following frameworks/tools in the project:

JUnit
For writing unit tests, the TDD way of course

Mockito
If there is a need to mock out anything during unit tests. I’ved used EasyMock for around 3 years now and really come to like it. But after reading about Mockito on the web I really wanted to try it out. Learning to use it as we speak but looks great so far. It makes my code look really clean and easy to read.

Fitnesse Slim
We have used Fitnesse to write acceptance tests for a while now but as a developer I don’t like the long cycles it imposes on my development. Maybe we have used it incorrectly… After hearing about Fitnesse Slim from a colleague I thought that it had some qualitites I really liked. Running Fitnesse from Eclipse I have really shortened the development cycle and I find it now much more appealing to write acceptance tests. It also gives me less code to maintain. The way we are using slim now means that we don’t test the infrastructure as much as we used to with “old” fitnesse. The intention is to use Fitnesse Slim to system test the component under test. This means however that we need to test the infractructure somewhere else…

Trinidad – In process test runner
This test runner gives us the possiblity to run the slim tests as part of our build. For more information refer to trinidad page on fitnesse.org

SoapUI
The intention was to use SoapUI to test the infrastructure and make some basic full value chain test. It is open source and extremeley easy to use. All we need to do is to point to the wsdl file of our web services and we are ready to test.

The project is just starting so we haven’t had any feedback yet on how this actually work in practice (apart from the initial experiments I’ve done). I hope that this simple setup can help us deliver features in a steady good pace, at the end of the day the success of the project isn’t measured on how many helpful tools were used but on time, features and quality.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s