The first story we write defines this report.

Any user of the system can run a report to view the changeset history of any project. This report is grouped by Visual Studio project and shows the files changed and dates.

In our current iteration, the customer selects this story, so they now need to define a test. We did not want them to select the story, but we are agile, and we have agreed that the customers select the priority of the stories. Since our rule also insists on an executeable test for each story, our customer must create a fitnesse test for this report. 

Our customer begins defining this story in a table to conform to the fitnesse format. The first test confirms the existence of fields. The next article in this series will show how to test against values in the report. 

The customer decides that in their test they want the following fields: changeset, project name, and the override comments fields. It is a bit cheeky of them, but it is their story and their requirements. So the customers create a table similar to what is above, except they need to have a true or false returned saying the field is there or it is not.  So for their first test, they come up with this:

This simple table tests for the existence or non-existence of fields on a report. The customer does not know how we hook this into the actual code and quite honestly you may not know how to hook this into actual code. That last part is a bit tongue in cheek, but keep in mind that this article is not a primer for fitnesse. To learn fitnesse fixtures, etc., go to the fitnesse web site, there are good tutorials there. This article does go over some of the fixtures, but we expect familiarity with the fitnesse software, or at least a willingness to become familiar with it.

The first column and row in this table defines our fitnesse method name, FieldsInReport. Since our fitnesse test code uses a columnfixture, the next row defines each column name (fieldname, datatype, and ok()).  The third row shows that the customer expects the field name Changeset to be on the report, and the data type is Text. That test should return a true is what the ok() field means. The next row is similar, and expects the report to have a field named ProjectName that is Text data type. The last row tests for a false outcome by looking for a field that they do not want on the report. Let us look at the code needed to run this report.