Software acceptance testing with FIT.

This is another article destined for the Ojektum news letter.

In the last episode of this newsletter I presented a case for improving software health through unit testing. Using JUnit or a similar test framework it is possible to achieve very high test coverage. This ensures that as a developer the code you write behaves in the way that was intended.

When developing test first one tends to start with very fine grained tests, gradually moving away from the detail to a level where collaborations are being tested. At this courser level we can develop tests for correct support of business workflow. This course level of test can often be specified by business analysts or testers; these can form a part of the software acceptance or integration testing.

The use of a framework like JUnit for these higher level tests can, however, present a problem. The skills to develop and understand a JUnit test may not exist in a BA or test team. FIT provides an alternative approach to this type of testing in an attempt to make the best possible use of testers, business analysts and developers.

FIT stands for Framework for Integrated Tests. Created by Ward Cunningham, this approach seeks to improve communication and collaboration in the specification of tests inline with business rules.

The FIT approach makes best use of business analysts and testers by having them present the expected results of an operation or work flow given specific inputs. Tables, such as that shown below, are used to present examples of correct system behaviour.

FIT is aimed at the validation of two specific types of business rule, calculations and workflow. The table above is intended to test the calculation of change. The columns for price and amount given represent the inputs to the calculation, change() is a calculation with an expected result. A table like this can be developed through collaboration between business analysts who understand the business requirements, testers who can raise special cases and test coverage issues and developers.

After producing a table like this the developer should produce a fixture to plumb the gap between FIT and the system under test. When run fit will duplicate the document under test applying highlighting to cells to indicate success and failure.

The second fixture type supported by fit allows the testing of workflow. This type of test can map directly onto a use-case flow or user story. This allows the author to show exactly how they expect the system to work without reliance on the user interface.

A table representing workflow is called an ActionFixture. Here we see four key words. Start indicates the fixture name, press invokes an event on the system under test, enter can push data into the system under test and check queries the system and compares the result with that expected. Since the user interface is likely to be the area of maximum change, running tests on the business layer can both reduce re-work and increase the frequency that tests are run at. This increased frequency improves the rate of feedback such that if a test fails the developers know sooner and it is easier to isolate the offending code.

A set of tables of this type form the acceptance criteria for a use-case. As development progresses and cells start to turn from red to green customer and developer confidence can increase.

While test driving development on a small scale ensures that our code does as we intended, acceptance tests using FIT show that our understanding is in line with that of our customer.

For more information about fit see Ward Cunnighams site