FIT Acceptance Testing Primer

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.

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
!|YakuFitAdapters.CreazaDocument|
|docNo|docType|docDate|partner|product|priceIn|priceOut|qty|warehouse|AdaugaDetaliu?|
|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
!|YakuFitAdapters.CreazaDocument|
|docNo|docType|docDate|partner|product|priceIn|priceOut|qty|warehouse|AdaugaDetaliu?|
|nir02|ReceptionInvoice|1.05.2006|furnizor1|prod1|2|3|10|gestiuneED|ok|
|nir02|ReceptionInvoice|1.05.2006|furnizor1|prod2|2|3|10|gestiuneED|ok|

!|YakuFitAdapters.CreazaDocument|
|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>
/// buy trough 2 documents
/// nir1|amd|1|100|
/// nir1|amd|3|102|
/// results:
/// inventory
/// amd|4|
/// </summary>
[Test]
public void TestAddToInventory()
{

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

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