FIT Acceptance Testing Primer

Extreme programming (XP) prescribes automated acceptance testing so that tests can be run often, while facilitating regression testing at a low cost. XP also insists that the customers specify the acceptance tests and keep them updated as the requirements change, and use these tests for test-driven development (TDD).

In the real world, applications keep growing in size and complexity, and change frequently; thus, the necessity for continuous testing constantly increases. But although the idea seems simple, in practicality it requires discipline and application. Can you really risk trying it?

One major roadblock to automating user acceptance testing has been the nonavailability of easy-to-use tools and frameworks. In this article, Narayanan Jayaratchagan show us how the Framework for Integrated Test (Fit) makes it easy to automate acceptance tests. In addition, it can also be used as an effective tool for communication and collaboration between users and developers.

The article is in four parts:

Fit for analysts and developers

Test calculations using column fixture

Refactoring test cases

Validate a collection of objects using a row fixture

Here's an idea of how Fit works: Fit describes frameworks that allow users to create acceptance tests using simple tools, like spreadsheets or wiki pages. In this example, there are 5 test cases: in each case the last column indicates the result expected for that test case. This is a much simpler way to test than with technical testing languages or expensive automated test suites.

sample.VerifyRating

team name

played

won

drawn

lost

rating ()

Arsenal

38

31

2

5

83

Aston Villa

38

20

2

16

54

Chelsea

38

35

1

2

93

Dummy

38

35

1

2

100

Wigan

38

26

7

5

75

These Fit test suites include automation - the tests can be set to run regularly during the day, displaying a kind of dashboard showing "All Green" when everything is passing. For more on Fitnesse (the version using wiki pages), visit Fitnesse.org .

I would definitely like to read how FIT was used in some real life projects and maybe a couple of more complex examples than the ones present on the net.As far as I understood FIT, it is a tool that allows better expressing client expectations. But I am wondering if this cannot lead sometimes to possible flaws in the system. Taking a simple example: for a client expressing that an withdraw with negative value should not "work" may seem innapropriate to be included in the FIT table, because they cannot see a way to reach this scenario. But the real acceptance test should account for this scenario too.

Fitnesse itself, if you download it, comes with the full suite of tests that he was actually built upon. They are very useful to study and extend. Also Ward Cunninghan's book is a very good place to start.

There is knowledge and discipline required to use Fitnesse methodically and at the right level of coverage. The team should provide this skillset if the customer doesn't have it... sometimes a BA takes on this customer support role, sometimes a developer, sometimes the PM. The customer brings their deep, subtle but unabstracted understanding of the domain, and the team member with analytical skills helps them abstract what is needed to test. Both of these skillsets are needed.

This conversation, in itself, is the beginning of the requirements elicitation process. It is much richer (higher bandwidth) and more pertinent (real questions answered in real time) than paper requirements. Sometimes the customer has to go away and come back with answers, when they discover that they have a blindspot, a part of the requirements they cannot address. Sometimes the team member has to go away and find out how to write the right kind of FIT table to express what the customer needs. If they don't think the answer can be found fast, sometimes they move that story to the next iteration and go on to another.

The end result should be requirements from the customer viewpoint. Full coverage would probably be confirmed and generated by someone in a testing role - BA, tester, developer, to fill out the acceptance test suite. As the developers work, more scenarios and tests may surface, and there would be an ongoing conversation with the customer on this (in-room, email, phone, IM etc.)

Someone (you?) gave an example of a customer arguing about the terms "number" and "character". This is really more of an attitude problem than semantic. When attitudes align, team members and customers accept corrections and information from each other, because they are all moving toward the same goal. This does take time! :-)

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.