By default, FitNesse executes Java tests, so the first thing we
have to do is make it run .NET tests.
The first two lines in
our test page tell FitNesse to
use the test runner from the dotnet2 folder:
!define COMMAND_PATTERN {%m -r fitnesse.fitserver.FitServer,dotnet2\fit.dll %p}
!define TEST_RUNNER {dotnet2\Runner.exe}The third line specifies the location of test classes:
!path D:\work\fitnesse\HelloWorld\bin\Release\HelloWorld.dll
Then comes the test table. FIT uses tables to describe both the tests and expected results, and binds these tables to our code. Tables may seem like a strange choice at first, but this turned out to be a very good idea. Rick Mugridge explains[5] that tables provide just enough structure to organise information properly, without getting in the way. The tabular form also allows test report and feedback to be given in the same form as the tests, which makes FIT and FitNesse easy to use. You have probably already worked out that in FitNesse you create a table by entering rows (lines) in which you separate cells with the pipe symbol (|). The first line of the table tells FitNesse which class to load (and how to execute the test):
!|HelloWorld.OurFirstTest|
FitNesse automatically converts
CamelCase[6]
names into page links,
but in this line HelloWorld.OurFirstTest
is a test class name, not a page link.
The exclamation mark
before the first cell in the table header tells FitNesse not to convert it to a page link.
It is good practice to put an exclamation mark
in front of the table even if the class name is not in CamelCase
form.
The test class extends
ColumnFixture, which maps public fields, properties
and methods to columns.
When you use
ColumnFixture, the second row of the table should contain field,
property
or method names:
|string1|string2|Concatenate?|
All subsequent rows are data rows: they contain parameter values and expected results:
|Hello|World|Hello World|
Each data row in a
ColumnFixture
table defines one test execution. Notice that
both parameter values and expected results appear in the same
row.
Columns that define an expected outcome have a question mark
after the method name. Fields and properties can also be used
to check expected outcomes in the same way. If a column header does not
end with a question mark,
FitNesse uses the corresponding data in the next row as test input, setting the parameter or field
value. If the column header does have a question mark, the method is executed
or the current field or property value is read, and the result
is compared to cell contents. So, the first data row in our
table
would be equivalent to the following NUnit test code:
HelloWorld h=new HelloWorld();
h.string1="Hello";
h.string2="World";
AssertEqual("Hello World",h.Concatenate());Here's an interesting experiment. Edit the test page (click Edit on the left), add a new data row with a wrong value in the expected results column, then run the test again. This time, the test fails (Figure 2.5, “Failed tests are clearly marked — and both actual and expected values are displayed”), clearly marking a problem both in the page header and in the table. Test results show both the expected and actual value for the failed test, so you can quickly see what went wrong.
