I was recently introduced to Fit (actually, FIT: “Framework for Integrated Testing”), AntFit, and Fitnesse. They’re pretty cool ideas for any kind of business development setting, and the technology is beautifully simple.

Basically, Fit fills a critical communication void: the communication of what the software should do and what it does do. I am a huge advocate of transparancy, since my experience has shown a lack of transparency to be the primary cause of breakdowns in development environments (e.g.: this on “soft deliverables” and other fun). Even better, this is transparency at the level business people are used to dealing with: electronic paperwork. You can take whatever documentation your people like to use, massage it very gently, and then plug it into your automated testing framework by creating a class that (even in Java!) is not even 100 lines.

The up-shot of this technical process is that you can take your state/requirement/story documents, and give them technical updates that are red light/green light in simplicity. Business people are also given an easy way to explore the existent capabilities of a software system, which enables them to make requirements based on changing the status quo (the very concept of iterative development).

AntFit is simply a plug-in to use Fit in Ant, which enables you to perform all of your tests any time you are doing a build. At my current contract, I have plugged this into a part of the continuous integration environment, so every deployment build contains both the code itself and a thorough reporting of the code’s functionality.

Fitnesse takes fit and plugs it into a Wiki. Although editting Wikis is not something I would expect most business people to know how to do, it certainly is something that developers can do. Since a major impedence to collective ownership is the lack of meaningful documentation, and since you can drop whatever you’d like as a link from a Wiki (say, a link to a Visio diagram or to an API homepage), it’s a major win to just have a Wiki in place to begin with. To then follow it up with the ability to execute segments of code on demand to illustrate behvaiors provides a really nice interactive-show-and-tell quality to the documentation.

I only see two things outstanding for improvements on these technologies. First, AntFit needs a way to optionally fail a build if there is a given test that fails — or at least set a property with the number of failures. Second, the core needs to be ported to Ocaml: it’s already been ported to most other modern business languages.

Popularity: 6% [?]

Trackback URI | Comments RSS