I like to make agile training as realistic as possible by having the team build working software in a realistic agile setting. So I like to use the game of TicTacToe because everyone knows how to play it and the team can quickly be productive in building and enhancing it.
It recently occurred to me that the requirements for TicTacToe could be readily explained through tables. It seemed very natural to use Fit/FitNesse as the vehicle to describe the game functionality. As a result I wrote some Fit fixtures and FitNesse pages to describe the TicTacToe game for my most recent training session.
And I think it worked out rather well …
Fit & FitNessse Background
Fit is a tool for enhancing communication and collaboration on agile teams. It does this by describing how the software should work through examples written in tables. There are many different types of tables which are backed by “fixtures” which serve as a bridge between the tables and underlying production code. Fixtures are quite easy to write.
FitNesse is a Wiki front-end for Fit providing an easy way to write, manage and execute Fit tests.
The diagram below shows a high level architecture for Fit and FitNesse:
The page below describes the winning combinations for TicTacToe as described in FitNesse:
Grey cells are inputs or descriptive text and the green cells are passed assertions. Failed assertions would be shown in red and any exceptions would show up as yellow. The Fit engine uses reflection to instantiate fixtures which then act as a bridge between the Fit tables and the production code. Fit handles all the table parsing
I find Fit to be a great way to express and radiate business intent. When I look at the above page it is easy for me to understand what the winning combinations are and the green cells let me know that the software understands too. Perhaps the “Turn” row which indicates whose turn it is shouldn’t be there so I should remove it. But other than that, the above does a great job of describing the winning combinations.
Fit story tests are a primarily a great collaboration tool between your product owner and the rest of the team. Ron Jeffries talks about the the 3 C’s of a story: card, conversation and confirmation. Fit story tests are the confirmation. The product owner and the team can collaborate and clearly define what “done” means for a story. This focuses the team on getting story tests to pass and helps avoid scope creep and getting side-tracked with other distractions.
Another benefit of Fit story tests is that they help drive ubiquitous language. The terms used in the story tests should be domain terms that are used consistently through the Fit fixtures and on into the production code. The need to express working examples in the constrained language required by Fit and the underlying fixtures requires the team to think carefully and consistently about the terms they use. I would expect the TicTacToe production code to have classes named “cell”, “mark”, “player” and so on.
What makes Fit even more powerful is that story tests can be run individually or as a suite. Tests can be run from build tools like Ant and NAnt and from continuous integration tools like CruiseControl and CruiseControl.Net. In other words, you can build up a regression suite of story tests and run them many times a day.
If you have tried Fit or FitNesse I would be interested in hearing how it worked or did not work for you.
If you haven’t either one why not take them for a test drive? No doubt about there are challenges setting it up and getting it part of the team’s culture … hmmm sounds like a good idea for another blog post ….