From Fit To Fitter

For about the past year I’ve been occasionally looking at Fit. When I first heard about it I perceived it as the shiny new tool that would radically modify the way user acceptance scripts are traditionally created, specifically for web applications. I was under the impression both analysts and testers could use Fit to the run scripts against a web application. No more laborious amounts of tests scripts coded by developers – that was the analysts and testers job now.

Well, after trying to read the site numerous times, downloading it and playing with it, I plain gave up. The doco was terrible and the code certainly wasn’t self-documenting. I encountered some sites that mentioned jWebFit, an extension to Fit for jWebUnit, but I couldn’t uncover any useful information on that either. I walked away from it all under the impression Fit was immature and generally unusable. But I was still intrigued as I heard rumors of it being put to good use.

Thankfully Fit is now Fitter! The Fit site has now been updated and it contains plenty of doco and examples to guide you through the process of understanding Fit. There’s even a new book on the way explaining Fit and the business processes supporting its full use. The doco on the site is fairly concise - within around 15 minutes I had Fit up and running with some experiments of my own. Here’s my take on Fit:

• Depending on how you use it, developers may still be required to produce a fair amount of code – Fit fixtures that exercise code being tested.
• Fit is a testing framework that it is completely agnostic of the thing being tested. You could perform any test (unit, integration or acceptance) using Fit.

Looking at it simply, Fit is a way of expressing what code to run, what values to use and what results to expect, all via a HTML table. View it as a layer above code that returns results – importantly that code should not be asserting the expected result. That’s Fits job, Fit asserts the result and displays the assertion result in a table. What that code does it entirely up-to the developer, hence there can still be plenty of grunt-work to do. While it’s a cool tool that can be used to express tests simply, a fair amount of development effort could be expended ensuring Fit fixtures do the job required of your test scripts. But this could be said of any code that has the “difficult to test” odor.

Enter jWebFit. After digging around I’ve discovered it’s a Fit fixture or two built on jWebUnit facilitating jWebUnit tests being expressed via Fit tables/scripts. If Web Apps is your thing, jWebFit promises to cut-down the development effort required to get acceptance tests running through Fit. So my original belief in Fit is realized - less developer grunt-work for web application testing. But beware. It’s documentation is non-existent and it’s not official, it can only be downloaded from jWebUnit’s CVS repository. Robert Watkins has played the tune I’m leading to before - use it at your own risk. But hey, as always if it’s free you can’t complain.

From what I’ve discovered, teams pursuing a collaborative team structure with analysts, developers, and testers working closer together (in true XP fashion) should consider using Fit and/or jWebFit but be wary that they are immature. It’s definitely a “try before you buy-in” deal, they will not work in every team, especially teams lacking the skill to support and expand fixtures.

P.S. Interestingly, the Fit site recommends the use of Word for analysts/testers to produce tables. For a cheap kick I tried Open Office 2 but unfortunately it produces HTML tables with <th> tags not liked by Fit.