Coding

Fitnesse and NUnit.

One of the current arenas of competition in the testing arena is the comparison with xUnit style testing and Fitnesse style testing.

Fitnesse is good at allowing users to enter test cases so long as they conform to a programmed template. It also is good at presenting the results and what was tested in a presentable way, typically with a web page. The Fitnesse style frameworks I have come across are not good at summarising the results in a one page summary.
xUnit style testing aren’t good at allowing the users to enter test cases. However with frameworks like mbUnit, they are now quite good at allowing lots of test cases to share the same code. They are good at summarising the results, but bad a presenting what has been testing.
In my experience, it’s quite rare that end users actually enter the data in a Fitnesse test case. It’s the programmers who use a Fitnesse style interface to present their test cases to end users. My conclusion is that it’s the lack of a presentation layer that is the problem with xUnit style testing.
It’s certainly good practice to use command-query separation when designing code in order to make it easier to test.
I propose that there is an ‘Assert. Command method added to the Framework. It takes a string as an argument and it acts as comment for the command sections. There are already asserts in place.

Code

namespace bank
{
using NUnit.Framework;

[TestFixture]
public class AccountTest
{
  [Test]
  public void TransferFunds()
  {
    Assert.Command (“Create source account”)
    Account source = new Account();
    Assert.AreEqual(0.00F, source.Balance);

    Assert. Command (“Deposit 200.00F in source account”)
    source.Deposit(200.00F);
    Assert.AreEqual(200.00F, source.Balance);

    Assert. Command (“Create destination account”)
    Account destination = new Account();
    Assert.AreEqual(0.00F, destination.Balance);

    Assert. Command (“Deposit 150.00F in destination account”)
    destination.Deposit(150.00F);
    Assert.AreEqual(150.00F, destination.Balance);

    Assert. Command (“Deposit Transfer 100.00 from source to destination”)
    source.TransferFunds(destination, 100.00F);
    Assert.AreEqual(250.00F, destination.Balance);
    Assert.AreEqual(100.00F, source.Balance);
 
  }
}
}

Output

TestFixture AccountTest                                         Status Count
Test         TransferFunds                                         Pass 1
Command         Create source account                                 Pass 1
Assert         AreEqual(0.00F,source.Balance)                         Pass 1
Command         Deposit 200.00F in source account                 Pass 1
Assert         AreEqual(200.00F,source.Balance)                 Pass 1
Command         Create destination account                         Pass 1
Assert         AreEqual(0.00F, destination.Balance)                 Pass 1
Command         Deposit 150.00F in destination account                 Pass 1
Assert         AreEqual(150.00F, destination.Balance)                 Pass 1
Command         Deposit Transfer 100.00 from source to destination Pass 1
Assert         AreEqual(250.00F, destination.Balance)                 Pass 1
Assert         AreEqual(100.00F, sort.Balance)                         Pass 1

So what does this presentation do? It presents a human readable output that can be presented to end users as to the details of what is going on in a test fixture. It’s the narrative of the test.

The Assert.Command passes when there are no failures between it and the end of the test or the next Assert.Command.

The count column lists the number of times the test has passed. Think about what happens when you have a loop. Typically here you would put a Assert.Command at the start of the loop. For example :-

Assert.Command (“Test all values in list”)

should probably the sort of comment that precedes each loop.
What then happens is each TestFixture, Test, Command and Assert can output their own little bit of XML that is then put together into a file at the end. You now have a narrative presentation that can be given to users, and they can read it, and make comments. They don’t need to understand the code underneath. In fact, the presentation is programming language neutral.

I’m not particularly happy with the presentation of the assertion details. Perhaps an expected value, against an actual value would be better. There is also the question of the message string in the assert.

Given the right presentation, where you can hide or expose the details, which isn’t difficult in an XML to HTML presentation, you end up with means of testing that does 99% of what Fitnesse does. It is just the question of allowing users to create their own test data.