Saved by Fitnesse

Jan Vermeir

We've been busy for a couple of weeks now refactoring a fairly complex code base of just under 500 classes. None of us really knew all the details about this part of the system, but we didn't let that stop us of course. After some regrouping/-shuffling/-factoring/*ing, the whole thing built OK and all unit tests were green again. All that was left to do was fix the Fitnesse tests. I remember thinking this should be easy since we had all those green unit test.

Evil laughter sounds.

We rely heavily on Fitnesse because it allows us to write specifications for our code in a way that is executable as well as understandable for others. You can even finish test cases before the coding is done so the tests work as part of the definition of done for a user story during a Sprint. The tests helped us to understand what the code was supposed to do, on a much higher level of abstraction than a unit test. This made it easier to find out what should be happening and fix the errors that were introduced by our refactoring. Because the Fitnesse tests make about 20,000 assertions we're pretty confident the code still does what it did before.

Comments (2)

  1. Marcello Leonardi - Reply

    February 8, 2011 at 9:48 pm

    Could you please explain a little bit you set up how you use fitness.

    What kind of project did you?
    How you integrate fitness?
    Does in work as part of the continous integration, like other unit tests?
    Did you do unit testing?
    What was the major part more unit test or more fitness?

    I tried in my project twice to introduce fitness, but the team does not adpoted it. I don't know what they don't like. They sad that the Idea is cool, but we never really start to write a lots of test suites...so after the first tests with fitness we give up. At the end we had only Unit Tests on Classes and for Services, but no Fitness Tests wich really would make visible which logic would be tested.

    So I would appreciate some more details about your work with fitness.
    Thank you in advance.

  2. Jan Vermeir - Reply

    February 9, 2011 at 8:53 pm

    Hi Marcello, thanks for your reply.

    The project we're working on started out as a processor that turned messages from one system into, well, different messages basically. Over time we added a complex user interface using Swing and some maintenance forms in Wicket.
    The message processing part is great for automatic testing using Fitnesse, so we decided to give it a try. We also believe in high unit test coverage (we strive for 80%) so we have tons of Junit tests as well.
    To give you an idea about size: currently our system has 3216 Java classes, 5563 Fitnesse test scenario's and 1021 JUnit test classes (the untested Java classes are probably Swing and Wicket, but I didn't check).
    While JUnit is a tool for Java developers that helps you design a method, Fitnesse is a tool for testers in Agile teams. We use Scrum and have one tester in a team of four or five developers. This allows us to write test cases at the start of a Sprint. This is done by testers and not by developers. I think this is very important because now you get two people (developer and tester) designing a function in stead of just one. Also, you can discuss Fitnesse tests with end users. Many test cases are named after bug numbers, illustrating another important use for Fitnesse: in stead of writing bug reports you just write a Fitnesse test and tell the developer to make this test green again.
    Our build fails if a JUnit test fails, but not if a Fitnesse test fails. In some cases the Fitnesse test fails by design because a tester may complete the test before the code is finished or writes a test that will be used to validate a bug fix.
    The Fitnesse tests take some time to complete, so we run them in our daily quality build. Or we start them manually like in the case I described in my blog. The idea is that a developer may check in code if all JUnit tests work for a given sub system and the Fitnesse test for his or her use case is green. Regression bugs and side effect errors are caught in the daily build.
    Finally, if you want to introduce Fitnesse in a running project I'd try to convince testers first. It gives them an important and useful role in your project: testers do not find errors but design software. Developers will thank you later when they are refactoring their code.

Add a Comment