An e-mail came through this morning illustrating one of the most common problems that developers have with FIT/FitNesse and probably the biggest cause of pain for the whole team with acceptance testing. The answer to the problem requires a change in the way people think and is typically the first thing I try to do when I get called in to help a team with FitNesse.
Here’s the e-mail:
I want to implement while and if conditions in fitnesse using java , particularly under DoFixture. Can any body know is it possible to implement conditional loops for DoFixture and something else.
I want to use while condition in following way:
|While|count|<|count| |statement1|statement1| |endLoop|
Theoretically you could do this with a custom fixture that sets the condition in the first table row (dofixture method call) and then returns a fixture which iterates through the rest of the table. But my question here is: why on earth would you do it like this?
Acceptance tests (in this case FitNesse pages) should describe the specification of what the software should do (or does in regression test), not how it the test is performed. Fixtures in the code should implement the script for the test. So, for example, instead of:
|While|i=0|i<5|i++| |put book in the cart|i| |confirm selection|i|
it is much much better to specify this as
|buy|5|books|
and then implement the loop in the buyBooks(int howmany) method in the fixture. The benefits of this approach are:
- The test is easier to read and understand. It is absolutely clear what the FitNesse page specifies and in a wider context it allows you to see important details while not concerning yourself with unimportant stuff. Business people and testers can understand this straight away. Developers will not get distracted by unimportant details. the test will allow you to have a much more meaningful discussion on the specification.
- The test is also easier to maintain in the future. Code refactoring will automatically propagate to fixture code, but not to FitNesse pages, so you want to move all the complexity outside of the pages into fixtures and make acceptance tests less fragile.
Mastering the difference between a specification (what) and a script (how) is probably the single most important thing that teams have to do in order to efficiently implement acceptance testing and really get the most out of it. Without that, tests quickly become a pain to maintain, they are not really understandable by anyone and lose their value as a communication enhancer straight away.
For a more detailed discussion of this, see David Peterson’s Concordion Technique page and key ideas from my latest book Bridging the communication gap.