We have put a lot of effort into automated testing. Not just unit testing but also system testing with Fitnesse. But it has come at a cost. In particular creating and maintaining our Fitnesse fixtures has become a burden.
In theory, Fitnesse should enable our domain specialists to write tests while the developers can get on with developing the features.
So far we haven't reached this nirvana.
For each major new feature we find ourselves either having to change our current fixtures or develop new ones. This taxes our development resources and our system tests lag behind development instead of leading it.
We must be able to do better than this.
Recently I've been wrestling with our fixtures - refactoring them to reduce the development debt. Finally they're starting to smell a little sweeter.
Here are some principles which have guided me ("best practices" if you like)
Principle 1. Structure fitnesse tests like unit tests.
They should have three distinct sections:
- setup the test data
- exercise the code to be tested
- perform assertions on the result
Principle 2 (corollory to Principle 1) Create separate fixtures for each of these phases.
One fixture say for priming the database with data. Another fixture for performing a query. And a third fixture for checking the result of the query.
Principle 3. Names are important.
By taking advantage of "graceful names" and choosing method names carefully our tests become more readable. They now look lke this:
|object id | is in query result? |
instead of
|objectId | checkResult?|
Principle 4. Fixtures should be tested too.
Writing unit tests for fixture code speeds up development and improves the quality and design of the fixtures.
Principle 5. Use dependency injection to decouple fixtures.
We use Spring to inject database connections, JMS queues and domain specific beans into our fixtures.
Nothing too radical there of course. But hopefully by concentrating on these key practices the returns from our investment in Fitnesse will improve.
