Summary
Have you heard about FIT yet? Even if you have, do you know what makes it signficantly different from other testing frameworks? Here is a re-introduction to FIT that highlights one of its most important features.

I had a weird feeling at the XP/Agile Universe conference in Calgary last week. I was looking through the sessions and the workshops, and I noticed how prominent FIT was at the conference. But that stood in stark contrast to what I've seen out in the field. FIT is nowhere near as well known as, say, JUnit. Fortunately, things are changing. More people are hearing about FIT, but sometimes I wonder whether they are hearing the most important things about it, the things that make it clear just how different it is from other testing frameworks. This blog entry is an attempt to introduce FIT to newcomers and put those differences in the foreground.

FIT stands for "Framework for Integrated Tests." It is a deceptively simple set of classes that Ward Cunningham developed to aid testing in a large variety of applications. On reading this you might say “Oh yes, well fine, why should I use it? I can call any vendor at random and get a site-license for an automated testing tool.” Well, you can, but FIT is free. You might reply, “Sure, but I can to go to SourceForge and download any number of automated testing tools.” True, but not only is FIT free, it is also significantly more useful than most mainstream testing tools. The reason is subtle and not widely appreciated. I’ll say more about that later, but first, here is a brief explanation of FIT for people who haven’t seen it before.

What FIT Does...

FIT is a testing tool, but at it’s core, FIT rewrites HTML documents. If you have a typical HTML document and you pass it to FIT, it will give you an exact copy, unmodified. The thing that makes FIT interesting is that it treats HTML tables in a special way. If you give it HTML with an embedded table that looks like this:

It will give you back an HTML document that looks the same, but there will be one difference: the table will look like this:

FIT interprets the first line of each table as the name of a fixture. A fixture is a piece of bridging code that interprets the table and talks to your application. It reads the table, row by row, and initiates actions against the application or passes it values; then it colors cells in the table based upon the results. In the example above, the cells containing “yes” in the “Attempt Fill” column matched values that were returned from the application for each row. Whenever a table value and the value returned by the application match, a cell is colored green, indicating a successful test.

Here is another example:

The table above hasn’t been run yet, but when we run it we'll be able to see a bug in our software. The table tells us that when we attempt to evaluate 1100 shares of PLI at a particular price, "Attempt Fill" should be "no." Let’s run it and see what happens:

FIT shows us that the software returns "yes" instead. FIT changes the table so that we can see both the actual and the expected values for "Attempt Fill" of PLI and it colors the error red so that we can see it easily.

There is much more to FIT than what I’ve described so far. The example above only shows the use of one type of fixture. There are many other kinds. Some allow you to script against an API, others help you check results of database queries, etc. You can also insert markers in your document that will be replaced with summary information about all of the tests run. One of the key benefits of FIT is the fact that all of the text in the HTML you input is completely preserved. This means that you can embed actual tests in project documents. When you run them through FIT you end up with documents explain the software and actually show what it does.

What Makes FIT Powerful...

If you’ve read the section above or had some experience with FIT, you probably have a sense of how it compares to other automated testing tools. Superficially, FIT looks very useful, but there is something subtle about FIT that you only notice when you compare teams that use it with teams who’ve attempted to use another tool:

When you use FIT, tests are decoupled from the development process.

Here’s what I mean by that. When you use FIT, you can write tests before the code that needs to be tested. After you write them you don’t have to rewrite them later or re-enter them when the code is ready.

Is this significantly different from other testing tools? What about scripting tools? Couldn’t we write little scripts or program against code that doesn’t exist yet? We could but there are two downsides; first of all, to do that you have to be a programmer. FIT presents a high level interface that non-programmers can use. Secondly, you end up tying yourself to a specific application interface. When you use FIT, the fixture defines communication with the application. If the interface you want to test against changes, you can modify the fixtures and leave the tests the same. This moves FIT past the “volatile interface” problem that plagues GUI-based screen scraping tools. With FIT you are decoupled. Once business analysts or customers in your organization know how to design FIT tests, they can work on them at any point during the development process. They can coordinate with the developers to decide on the fixtures that they need for their tests to run completely, but they can still run the tests at any time. At some point, the tests will start to turn green. Nobody has to rewrite them or transliterate them from a test design document. You can write them early, in your documentation, and run them to see progress.

Recently, I’ve visited some teams that have run into trouble with their home-grown testing frameworks. They took significant time to create them, gained organizational buy-in and then they discovered that they had a bottleneck: Their testers couldn't work concurrently with their developers. They had to wait until developers solidified the user interface of the application before they could start their work. This limited the work that testers could do until they got the software, and it also skewed the work that developers did in an iteration: they had to stabilize the UI before they did anything else. It’s unfortunate that they discovered only later that decoupled testing could have helped them from the beginning.

You can get more information about FIT at (http://fit.c2.com) and FitNesse (a hosting environment for FIT tests) at (http://fitnesse.org). Both sites have plenty of information, and they are well worth a look.

Talk Back!

Have an opinion? Readers have already posted 4 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Michael Feathers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Michael has been active in the XP community for the past five years, balancing his time between working with, training, and coaching various teams around the world. Prior to joining Object Mentor, Michael designed a proprietary programming language and wrote a compiler for it, he also designed a large multi-platform class library and a framework for instrumentation control. When he isn't engaged with a team, he spends most of this time investigating ways of altering design over time in codebases.