Unit Testing With MbUnit
Thursday, July 10th, 2008In general either code works or it doesn’t and it’s easy to tell whether it does or doesn’t work. At least until you reach a certain level of complexity. At some point a project gets large enough that you can’t tell which project/dll your error is coming from, let alone which of the 100K or even 50M lines of code is doing naughty things.
Today I had a problem that was easier to solve by creating unit tests to point out where the flaw was. The tool uset? MbUnit.
Here’s an example of an MbUnit test I wrote in order to find a string processing bug:
using System;
using System.Collections.Generic;
using System.Text;
using MbUnit.Framework;
namespace UnitTests
{
[TestFixture]
public class MUDStringTests
{
[RowTest]
[Row(12, "12.box", "box")]
[Row(1, "cheese", "cheese")]
[Row(1, "1.pie", "pie")]
[Row(1, ".chicken", "chicken")]
public void NumberArgument(int expectedValue, string inputString, string expectedOutput)
{
string str = String.Empty;
Assert.AreEqual(expectedValue, BasternaeMud.MUDString.NumberArgument(inputString, ref str));
Assert.AreEqual(expectedOutput, str);
}
}
}
What this does is check whether we’re getting the expected output when we give a certain piece of input. It’s handy for detecting anomalies without having to boot up the server and/or mess with production code. Mind you, there’s no such thing as ‘production code’ since we don’t have a server up yet, but this sort of thing is likely to be handy in the future.
I’m not the type that has any chance of turning into a ‘write the unit tests first’ and ‘unit tests are more important than code’ evangelistic freaks, but in some (or many) cases it can be easier than using trial-and-error to track down a bug.
I still hate the way WordPress formats my code.