Story Testing

Story Testing is a actually a communication process in which the Customer fleshes out the business details of a User Story. The Story itself is deliberately thin on details, and it is the story tests that provide the required details in order to build the Story. Typically, sample data is used that shows the inputs and expected outputs.

These tests are written by the Customer and/or Domain Experts - the people who know and understand the business! Once the Story Tests have reached a reasonable level of completion, the Developers will work with the Customer to automate the tests. Additionally, Testers may provide guidance to the Customer while the tests are initially being written, and will also contribute their own tests.

The Story Tests are not only a verification tool for a system. They are used by the Customer and Domain Experts to define what a system should do, and in some ways how to do it. The tests are also automated, thus forming an Executable Specification.

The Story Tests are automated using tools such as FIT - the Framework for Integrated Tests. FIT provides a mechanism for using HTML tables to describe the tests, execute tham against the system's code, and report the results.

In addition to FIT, there is FitLibrary which extends FIT with many useful features and test fixtures. There is also FitNesse, which is a wiki front-end for FIT.

Consider the following sample User Stories:

Some of the Story Tests for those two stories would look something like this:

These tables define from a business perspective what is expected from the system. However, they need some work in order to be able to be automated by the developers. If, for example, we were using FIT, we would have to build what are called Fixtures.

A Fixture is code that is used to take the inputs from the story test tables, call the application code and compare the results. For FIT, we have to modify the tables somewhat:

In these tables, the first row identifies the Fixture to be used. In our case, PreferredCustomerFixutre and CustomerDiscountFixture. These refer to classes that must be visible to the FIT code at runtime.

The column names PurchaseTotal and CustomerType represent public fields in the Fixture code. The FIT framework will set those fields to the value in each row as it is executed.

Note that the columns PreferredCustomer and Discount have parentheses at the end. This indicates to FIT that it should execute methods with those names in the Fixture. FIT will then compare the result from the method call with the value in the table cell.

After executing the tests, FIT will generate an HTML report showing the results. The tables will be coloured to show if they succeeded or failed. For example:

These examples show only one type of Fixture, known as a ColumnFixture. For more information about FIT, FitLibrary and other types of Fixtures, visit our Resources page.