FIT Acceptance Testing Primer
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
|team name||played||won||drawn||lost||rating ()|
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 .
FIT in real life
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.
.w( the_mindstorm )p.
Re: FIT in real life
We started to use Fit/Fitnesse with c#/.NET and we find it very useful. We are using it directly from Fitnesse:
Receptie finalizata dar anulata
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:
/// buy trough 2 documents
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);
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.
Re: FIT in real life
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! :-)