Book Review: Fit for Developing Software

Fit for Developing Software: Framework for Integrated Tests, $44.99
by Rick Mugridge and Ward Cunningham
Prentice Hall PTR, 2005
355 pages
Examples in Fit and Java
ISBN 0-321-26934-9
http://www.amazon.com/exec/obidos/ASIN/0321269349/larkware-20
http://www.amazon.ca/exec/obidos/ASIN/0321269349

Despite the nondescript name, Fit represents a confluence of three different strands of software development practice: requirements management, testing, and agile development. The Fit system was originally developed by Ward Cunningham, who you will notice is one of the co-authors here, so you can view this as the definitive text on the subject. Fortunately, it's a very readable book for all that, whether you're a business user, tester, or developer. Part of the reason it's readable for so many audiences is that it's really two books in one: the first half looks at the external-facing interface of Fit and talks about how business users, testers, and developers can use it to communicate requirements and check on whether software is fulfilling those requirements. The second half of the book turns to Fit's internals, grubbing around in its Java implementation and showing how developers create "fixtures" to hook up Fit tests to the system under test. (Fit is not, by the way, exclusively for Java developers; the same system has been implemented for quite a few other languages, including the major .NET languages).

From the end user point of view, Fit is a remarkably simple system. Tests are stored in tables. If you're used to highly-structured, tightly-constrained, unreasonably-complex testing systems, hold on to your chair: there are only three simple types of tables, and Fit doesn't care whether you keep your tables on a spreadsheet or an HTML page, or how much other eye candy and junk you scatter around the tables in the interest of documenting them and making things look pretty. Indeed, the FitNesse system wraps Fit up in a wiki. When you run Fit on a group of tests, it indicates which ones passed by color-coding cells in your tables the expected red or green (as well as yellow for errors and gray for tests not run). Anyone with half a brain and reasonable motivation should be able to understand how Fit tests are constructed and what they mean, which is what makes Fit such a good system for communicating between the various people who need to define and implement the requirements for a piece of software.

Behind the scenes, life is a bit more complex. To hook Fit up to your own code, you'll need to be fairly comfortable with object-oriented programming. This is one area where this book is a great advance over the previous Web-based documentation: it not only shows the main line of hooking up easy tests, but talks about a batch of the harder edge cases and gets at many of the details of how to make Fit work in various potentially troublesome situations. You can tell that there's real experience with Fit behind the pages here, and that Fit has evolved in response to actual use; it's not an ivory tower system. Much of the book is held together by a reasonably realistic series of examples that show how one company with an existing base of legacy software could gradually introduce Fit to its processes and then use it to test its software.

Like many other agile processes, Fit isn't for every system. It's easy to come up with examples of very large systems where it would be difficult or impossible to scale Fit's informal and relatively unstructured approach to work. But smaller organizations, particularly those that are feeling a disconnect between business users, testers, and developers, ought to take a look at the processes enabled by Fit as a way to enhance communication and get some working software delivered with less pain to all concerned.

Mike Gunderloy is the lead developer for Larkware and author of numerous books and articles on programming topics.