Get Fit ( but not necessarily FitNesse )

As I said in “About Me”, I believe in using whatever tool makes sense for what you are trying to test.  In a recent situation, we needed to test a “rules engine” for modifying URLs.  The test cases were pretty straight forward.   They were the current URLs and what we expected them to be after being modified by the rules engine.

The test tool we chose for this situation is “Fit”.  You may have heard of Fit and FitNesse before.  FitNess is the wiki that was originally used to drive Fit. For background information on Fit and FitNesse, go to http://fit.c2.com/

There are a number of drawbacks of using FitNesse to drive the tests.  The two most significant ones are that it is difficult to do version control of the test cases and that only one set of tests can be run from the wicki at a time.

The solution was to run the tests with Fit but not use FitNesse.  This solved the two main problems of using FitNesse.  First, the tests could be put under version control.  Second, anyone can checkout the tests and the Fit driver to their system and run the tests without worrying if someone else is running the tests.

We chose Fit because the test cases are pairs of inputs and expected outputs.  Fit allows you to specify a table with a column of inputs and a column of expected outputs.  Each row is a test case with input and the expected output.  We knew from the beginning that we were going to have a large number of test cases.  Using a table structure made it easy to manage data for the tests.  The table below shows an example of what inputs and expected results might look like.

inputurl1 expectedoutputurl1
inputurl2 expectedoutputurl2
inputurl3 expectedoutputurl3

Anyone who is familiar with the application should be able to understand the inputs and expected results.  Developers as well as testers are able to create test case pairs.  Developers can run the tests on their system while they are writing new code.

The test cases we developed fell into four categories.  The first was the existing URLs that we expected to be modified in a certain way.  The second was the existing URLs that we expected to be unmodified by the rules engine.  The third set of cases were ones where there were currently not any existing URLs but test URLs that should be modified in a certain way because of the rules.  The fourth set of cases was currently non-existent URLS that should not be modified by the rules engine.

We have implemented this testing system for the rules engine and it has proven effective.  There are about 300 test case pairs.  The test cases were developed by two testers and three developers.

For a further discussion of where Fit can be used as an effective testing tool, see the following link:

http://awta.wikispaces.com/Fit+-+Fitness+Implementation+Strategy

Advertisements

Tags: , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: