jones.busy

technical musings of a caffeine converter

NAVIGATION - SEARCH

Enabling external testing of .Net code with Fitnesse

Unit Tests not only offer an excellent entry point into writing good code with a TDD approach but can also offer a health check in the form of automatic regression testing for subsequent changes that may have had an unintended impact elsewhere in the system. But the tests are only valid for what they cover and often are only visible to the dev team. CI and automated builds often come with the tools to increase the visibility of these tests but still only offer a signature-level view of what is being tested.

Whilst searching for a way to elevate are tests, I was pointed in the direction of Fitnesse. A wiki based web tool that not only allows non-technical users to view tests but, to some extent, to specify and run them. It’s not a wrapper around existing unit tests, although I found I could use existing unit tests to help drive the ‘published’ versions. You will have to write some code to enable the tests to be run, but I found it to be a healthy exercise as the code you have to write forces you to consider what variables are of interest in each scenario and this can be done in collaboration with a tester, business analyst, or end user.

To get started, head over to the Fitnesse Download Page and download the fitness-standalone.jar file (yes, it does run on java, but is perfectly capable of running .net code)

Browse to the downloaded file’s location in a command prompt (runas Admin). I already had the standard port 80 in use so needed to specify a different port for install:

java -jar fitnesse-standalone.jar -p 8080

It’s worth browsing then to your local Fitnesse home page to ensure all installed correctly (http://localhost:90 in my case)

Next up you need to install a runner for your framework. The runner is akin to a unit test runner such as nunit and is responsible for loading in your .net dll and running the tests against it. There are two approaches with Finesse to testing – Slim and Fit, but the FitSharp runner manages both for .net testing so head over to its download page, grab the right version for your framework and unzip to an appropriate directory (in my case, c:\apps\fitSharp).

Next up is to set up a new suite ready for testing in your Fitnesse wiki. You can either create and then add a link to it or, as I prefer, add a link first then user the ‘Create New’ shortcut to do it for you. Click on the Edit menu to open up your home page ‘source code’.

You’ll see some odd table notation defined by lots of these: ||

To add a new link into the table, paste the following in (change the names to suit your needs but be wary which element refers to what component etc.):

| [[My Test Suite][.TestSuite]] | ''Test Suite Link'' |

Click Save, and you should see the following in your table:

image

If you click on the [?] you will be taking to a create page form. Just click Save in that form then you can head back to the home page and see that ‘My Test Suite’ has now become a proper link to that new page. Navigate to your TestSuite page (you can change these names to suit your needs), click Tools from the menu, then Properties.

Select Suite in the top box under Page type, then click Save Properties

image

Now head over to your VS solution. Let’s assume you have the following setup

image

So, FitnesseExample is a class library containing some dtos and view models (it would obviously contain a lot more). FitnesseExample.Tests is my test project (a plain class library with Rhino Mock and NUnit add through nuget but feel free to head down which ever testing route you prefer)

Given a view model as follows:

public class ExampleViewModel { public DateTime BookingDate { get; set; } public int TicketNumber { get; set; } public decimal TicketPrice { get; set; } public decimal TotalAmount { get { return TicketNumber * TicketPrice; } } public bool CanCommit () { return BookingDate > DateTime.Today && TicketNumber > 0; } }

I might create the following test:

[Test] public void CannotCommitIfBookingDateIsNotInTheFuture() { // arrange var vm = new ExampleViewModel(); // act vm.BookingDate = DateTime.Today; vm.TicketNumber = 1; // assert Assert.IsFalse(vm.CanCommit()); }

For the purpose of Fitnesse, this is where you would most likely deviate from the traditional route of unit testing. The first exercise would be to define the test:

CannotCommitIfBookingDateIsNotInTheFuture

Then, given the following criteria:

“Bookings cannot be committed unless the booking date is in the future and at least one ticket has been selected”

Work out which variables should impact this decision

TicketNumber & BookingDate

And also which variable needs to be checked:

CanCommit()

I use the term ‘variable’ in a very loose sense as this conversation would not involve the code itself so variable could refer to a method’s return value, a property etc.

The next step is to create a Decision Table – this is a column/row based format to defining the test and goes a bit like this:

|TESTNAME|

|VARIABLE_IN_A | VARIABLE_IN_B| .. | VARIABLE_OUT_A? | VARIABLE_OUT_B? | ..||

|TEST_INPUT_A | TEST_INPUT_B| .. | EXPECTED_OUTPUT_A | EXPECTED_OUTPUT_B | .. ||

It’s a bit convoluted – especially to a non technical mind so you can use Excel to set it out instead if preferred. In the case described above, I would have the following:

image

Note that the output variables are defined by a suffixed question mark. Back in Visual Studio, you now have to write a fixture class that will allow these variables to be set, read and acted upon. Here’s the fixture class for the above test:

namespace FitnessExample.Test.Fixtures { using System; using System.Globalization; using FitnesseExample.ViewModels; public class ValidationMustBePassedBeforeCommitting { private readonly string[] dateFormats = {"dd/MM/yy", "dd/MM/yyyy"}; private ExampleViewModel viewModel; public void Reset() { viewModel = new ExampleViewModel(); } public void SetBookingDate(string bookingDate) { var date = DateTime.ParseExact(bookingDate, dateFormats, null, DateTimeStyles.None); viewModel.BookingDate = date; } public void SetTicketNumber(int number) { viewModel.TicketNumber = number; } public int TicketNumber() { return viewModel.TicketNumber; } public bool CanCommit() { return viewModel.CanCommit(); } } }

UPDATE: I have since discovered that you can actually use Properties instead of the SetX() and X() approach for macthing so, in the example above, you could have a Property TicketNumber with a getter and setter that replaces the two methods.

It’s probably self-evident how it fits but here’s the breakdown:

1. The class is effectively the text from the first row, without spaces (keeping to Camel case convention)

2. Each input variable must have a matching void method prefixed with Set so Booking date needs SetBookingDate… etc.

3. For DateTimes, you can take in a string and convert based on one or more formats

4. For output variables, it’s simply a method that returns the expected value in Camel Case

You need to build your test project and copy all dlls from its output target dir to a test directory – let’s assume we are going with “C:\Fitnesse\” for now.

Head over to this directory and create a new xml file, “example.config.xml”. Paste in the following text:

<?xml version="1.0" encoding="utf-8" ?>
<suiteConfig>
  <ApplicationUnderTest>
    <AddAssembly>c:\fitnesse\FitnesseExample.Test.dll</AddAssembly>
    <AddNamespace>FitnesseExample.Test.Fixtures</AddNamespace>   
</ApplicationUnderTest>
  <Settings>
    <Runner>fitSharp.Slim.Service.Runner</Runner>
  </Settings>

</suiteConfig>

What this is telling the Fitnesse runner is what dll you are using to test, what sort of runner you are using, and any namespaces you are using to allow the runner to locate the fixture classes.

Back in your Fitnesse wiki, navigate to your Test Suite page, click Edit, and paste the following in:

!define TEST_SYSTEM {slim}
!define slim.timeout {60}
!define COMMAND_PATTERN {%m -c "c:\fitnesse\example.config.xml" %p}
!define TEST_RUNNER {c:\apps\fitSharp\Runner.exe}
!path c:\fitnesse\FitnessExample.Test.dll

This tells the page where to find your config file, where to locate the runner executable and the path to your test dll (I did wonder why we have to set the path here as well as add it to the config but if I left out the path, the tests did not run).

Underneath this test, paste the following:

[[Booking Tests][.TestSuite.BookingTests]]

Save the page and then click on the [?] next to the new link to create a page. Go back to your spreadsheet and select the columns and rows containing the test and copy them to your clipboard. Back on the test page, paste in the spreadsheet contents and then click the Spreadsheet to Finesse button:

imageimage

This converts the pasted text into a Decision Table. Click Save and you’ll see this now appear in your test page:

image

Now Click Tools –> Properties, and set the Page type to Test, and then click Save Properties

image

You should now see a Test button appear at the top op the page. Give it a click and see what happens. With any luck, it’ll be something similar to below – the important thing now is that the tests have run, regardless of whether they pass or not:

image

 

 

 

 

 

 

 

 

 

 

If you do not get this (and trust me, I spent a number of rounds before I got to this stage), check, check and check again on your paths, config files etc.