Acceptance Testing with FitNesse: Multiplicities and Comparisons

By: Michael Sorens

FitNesse is one of the most popular tools for unit testing since it is designed with a Wiki-style interface that makes it very easy to set up individual tests. Michael Sorens' sixth article in his series delves into the nuances of multiple inputs vs. multiple outputs, multiple rows vs. multiple columns, as well as things that can trip you up when attempting to validate a value.

Contents
Using FitNesse, Part 6
Dealing with Multiplicities
Combine Multiple Method Calls in One Test Table
Combine Multiple Database Queries in One Test Table
Work With Multiple Outputs
Work With Multiple Output Rows
Comparisons
Validate Approximate Values
Be Aware of the Precision of Your Database Values
Watch Out For Whitespace
Know What Comprises Your Database Key

FitNesse is a wiki-based framework for writing acceptance tests for software systems. If you are not familiar with FitNesse, Part 1 of this series walks through a complete .NET example from writing the test in your browser to writing the C# code-behind. While FitNesse provides a rather nifty and user-friendly way to write acceptance tests in general, in practice there are plenty of quirks and glitches to watch out for. This and the subsequent parts of this series provide “tips from the trenches”, i.e. an accumulation of tips collected from intensive use of FitNesse on a daily basis to alleviate or avoid many of those pain points.

Dealing with Multiplicities
Combine Multiple Method Calls in One Test Table

Do not use separate test tables for similar calls to the same method (i.e. calls that have the same signature). Compact your test vertically by combining calls to the same method in a single test table. This also adds additional structure to your tests by making it obvious that multiple calls to a method are, in fact, calling the same method.

Combine Multiple Database Queries in One Test Table

A similar concept applies to combining multiple database query results. Rather than invoke the same query with a different parameter, make use of SQL language constructs. In this example use IN instead of a single EQUALS comparison in the WHERE clause. (Remember that within queries, @name is the notation to reference a symbol.)

Work With Multiple Outputs

All the examples thus far have dealt with test tables that take one or more inputs but produce exactly one output. Part of the reason for that is that it is natural to imagine an equivalence relationship between a test table and a method, and a method returns just one output. That is fine for many cases. But you are not limited to that mental model. Rather, consider that you are communicating with a class rather a method, and you have much more flexibility.

For each set of inputs, then, you can get not just one output but one row of output, though this output “row” is adjacent to—rather than under—the input “row”. Consider a simple Echo fixture class, shown below. I have contrived it for purposes of discussion to return up to two outputs, Result and ResultTimesTwo, for a given input. This is done by deriving from the ColumnFixture class, likely the most common pattern to use in FitNesse.

Work With Multiple Output Rows

The commonly used ColumnFixture class, as shown previously, allows you to get multiple return values (i.e. different columns) but returns only a single row per set of inputs. RowFixture, on the other hand, may be used to return any number of associated rows. In this example, the InvoiceDetailsFixture class inherits from RowFixture rather than ColumnFixture, taking no inputs and returning a series of rows each containing two outputs.

Comparisons
Validate Approximate Values

Up until now, you have seen test assertions done by filling in a cell with a value that must be matched exactly by the returned data; otherwise, that cell is marked as failing. FitSharp provides a number of cell operators that give you more expressiveness than just an equality check. For example, once you load any of these FitSharp string operators you can do partial string matches as shown. (Note that these cell operators are a replacement for the old cell handlers.)

Be Aware of the Precision of Your Database Values

Take care with specifying precision when you retrieve and compare certain data types from a database. Besides the obvious consideration of floating point numbers there are other key types to consider as well, such as dates and times. This statement…

SELECT CreatedDate FROM...

...retrieves the time down to the millisecond—probably not what you want! Rather convert it to a precision relevant to the task at hand. If you only want to validate the date and ignore the time altogether, use something like this (highlighted in red for emphasis):

Full article...

Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/