Beautiful Testing

Driving Development with Tests

Mastering TDD at the unit level seemed more straightforward than learning how to use business examples and business-facing tests to guide development. FitNesse was clearly a good tool for this purpose, but figuring out the right approach involved lots of trial and error.

Experimenting

We found that FitNesse tests were really easy to write. In our zeal to turn business examples into executable tests, the product owner (PO) and I got carried away. Our team had a difficult, high-risk theme coming up that involved complex algorithms and had a hard deadline. The PO and I spent days writing executable FitNesse tests for different parts of this theme, well ahead of the team starting on the stories for those features.

When the first iteration of working on the theme began, the programmers’ reaction to our detailed FitNesse tests was: “Huh?” They couldn’t see the forest for the trees. The complex, highly detailed test scenarios didn’t give them a “big picture” of what they needed to code. In addition, the test design wasn’t compatible with the code’s architecture.

We had to back up, provide some “big picture” examples, and rewrite all the FitNesse tests, but our team learned a good lesson. We now write only high-level acceptance test cases in advance of coding. We don’t start writing detailed, executable tests until someone picks up one of the coding task cards.

There’s no prescription you can follow for knowing when to write tests, how many tests to write, and ...