FIT Overview

FIT (the Framework for Integrated Testing) is an outgrowth of Ward Cunningham's experience in writing acceptance test frameworks in a number of different projects over the years. The original version is in Java, and can be found at fit.c2.com. This version is an extension of Simon Michael's port to Python.

This version also contains most of Rick Mugridge's Fit Library in a fully integrated form. The Fit Library is documented in a series of specification tests in the fitLib.tests folder as well as several pages in this documentation set.

There is an excellent book, "Fit for Software Development" (Prentice-Hall July 2005, ISBN 0-321-26934-9), by Rick Mugridge and Ward Cunningham, which may be acquired through your usual bookseller channels. Some differences between the version of Fit and FitLibrary documented in the book and PyFit can be found here. It's written for both the non-technical customer and the developer. Highly recommended.

FIT takes the approach that the acceptance tests are part of the requirements, and as such they should be readable and understandable by the customers who are having the software constructed. Ideally, Fit style acceptance tests are written by a team consisting of customers, developers and testers, since each has different perspectives and expertise to bring to the job.

This philosophy meshes very naturally with Extreme Programming. XP attempts to minimize the use of documents which can get out of date. Accordingly, XP strongly suggests that requirement documents be executable; this insures that they have to be kept up to date, or the tests will not pass.

One of the objectives of the FIT system is that FIT tests can serve as business documentation, and can outlive a particular implementation of a system.

FIT tests are HTML tables embedded in an HTML document. This can be produced by any tool that can create an HTML document with tables, including the usual run of word processors and spreadsheets. One increasingly popular option is to use the FitNesse tool from ObjectMentor.

Besides FitNesse, there is also an experimental GUI front end called Fitster, and a Fitster port which is being developed for the Eclipse IDE.

Tables are processed by fixtures, which are small programs that connect the table with the software under test. The first row of a table contains the fixture name in the first cell, and any parameters needed by that fixture in succeeding cells. The remaining rows are interpreted by the fixture itself. The fixture name is simply the module name and class name, separated with dots as in the Python import statement. If the module and class have the same name, then it is not necessary to repeat them. For example, the name "fit.ColumnFixture" loads the class named ColumnFixture in the module named ColumnFixture in the package named fit.

Rick Mugridge's FitLibrary, included with this release, takes a different approach. He prefers that there be as little "technology facing" data in the acceptance tests as possible, so his DoFixture can be used with exactly one invocation of a fixture name right at the beginning. The fixture then handles the rest of the interaction. See the FitLibrary documentation for examples.

Alistair Cockburn, in his excellent Hexagonal (Ports and Adapters) architecture papers gives one of the best rationales for where FIT connects with a system. There's a diagram in the middle that I've attempted to write several times; he's not only done a much better job, the surrounding paragraphs are a much better explanation than I've ever been able to give.

The documentation set contains:

  1. A guide to the distribution
  2. Using FIT
  3. A guide to the samples and tests
  4. Guide to Writing Fixtures
  5. Release 0.8 changes