# FIT Acceptance Testing Primer

| by Deborah Hartmann Preuss 0 Followers on Jun 19, 2006. Estimated reading time: 1 minute |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

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:
1. Fit for analysts and developers
2. Test calculations using column fixture
3. Refactoring test cases
4. 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 .

Style

## Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

## Get the most out of the InfoQ experience.

### Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

FIT in real life

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.

./alex
--
.w( the_mindstorm )p.

Re: FIT in real life

Hi Alex,

We started to use Fit/Fitnesse with c#/.NET and we find it very useful. We are using it directly from Fitnesse:

Receptie nefinalizata
|nir01|ReceptionInvoice|1.05.2006|furnizor1|prod1|2|3|10|gestiuneED|ok|
|nir01|ReceptionInvoice|1.05.2006|furnizor1|prod2|2|3|10|gestiuneED|ok|
----
Receptie finalizata dar anulata
|nir02|ReceptionInvoice|1.05.2006|furnizor1|prod1|2|3|10|gestiuneED|ok|
|nir02|ReceptionInvoice|1.05.2006|furnizor1|prod2|2|3|10|gestiuneED|ok|

|docNo|docType|CloseDocument?|
|nir02|ReceptionInvoice|ok|

One of the nicest things about it besides the fact that you can actually run the tests from fitnesse directly is the Fit notation, which we started to use even in our unit test code:

/// <summary>
/// nir1|amd|1|100|
/// nir1|amd|3|102|
/// results:
/// inventory
/// amd|4|
/// </summary>
[Test]
{

new PurchaseEvent(this.w, this.p, 1, 100).Process();
new PurchaseEvent(this.w, this.p, 3, 102).Process();

InventoryAccount i = this.w.InventoryFor(this.p);
Assert.AreEqual(4, i.Balance);
Assert.AreEqual(2, i.Entries.Count);
}

Another example is: danbunea.blogspot.com/2005/12/tdding-sales-repo... where I defined the requirements as a Fitnesse test. Hope to write more on the matter.

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.

Thanks,
Dan Bunea
danbunea.blogspot.com

Re: FIT in real life

You are right, Alex.

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! :-)

deb
Close

#### by

on

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Login to InfoQ to interact with what matters most to you.