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:

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 .