I would like to refer to gojko’s latest blog entry, which made me a bit thoughtful. Here is the actual link I’m referencing: Using FitNesse pages as templates.

At my company we started back around easter to get rid of our old tests, which were

• build on a script generator, which generated shell-scripts

• had a “shared fixture” strategy with high interface sensitivity to nearly all DOC of the SUT

• suffered from test chaining and slow tests

I’m glad I now know all those fancy words after reading through xUnit Test Patterns :-)

We started using FitNesse. Actually I was the only one in our five person team, who had read the book. By coming up with mechanisms to be able to use “Shared Fixtures” and re-use an add-on component of our SUT for test account maintenance, we introduced a good framework, which is easily extensible etc. Since we did not get the support from our developers, which would have been necessary, we had to find ways to compensate for that by introducing unit tests for our generic test helpers, using refactoring and so on.

Parallel to our approach a colleague started to build a framework based on FitNesse as well. At the moment there are

• complicated long tables

• high level of details

• test table chaining

built into this test suite.

Currently I’m facing the situation, that we got the assignment to unify both approaches somehow. Since I’m pretty much convinced by the context-driven school of testing, I believe that both approaches have more or less a good reason to exist. After reading through gojko’s blogentry I think, that screwing up the system by not cooperating should not be a general solution. Since FitNesse has several ways to screw things up, stay aware of the hammer argument:

If I got a new hammer, everything looks like a nail.

Try realising instead that not every hammer fits to any nail.