Unit Testing – Look on my works, ye Mighty, and despair!

Partial function application (in C#)

January 11, 2012January 11, 2012Graham HayLeave a comment

I often use delegates (e.g. Func<> or Action<>) to make code testable that would otherwise be using static methods. In this case, Trace.WriteLine:

public class TraceLogger : ILogger
{
	private readonly TraceSwitch _traceSwitch;
	private readonly string _category;
	private readonly Action<string, string> _write;

	public TraceLogger(TraceSwitch traceSwitch, string category, Action<string, string> write)
	{
		_traceSwitch = traceSwitch;
		_category = category;
		_write = write;
	}

	public void Debug(string message)
	{
		if (_traceSwitch.TraceVerbose)
			_write(message, _category);
	}

	public void Info(string message)
	{
		if (_traceSwitch.TraceInfo)
			_write(message, _category);
	}
	
	etc...
}

Every time the write action is called, the second argument is the same. So we can save ourselves some duplication by using partial function application (not currying, apparently!):

public class TraceLogger : ILogger
{
	private readonly TraceSwitch _traceSwitch;
	private readonly Action<string> _write;

	public TraceLogger(TraceSwitch traceSwitch, string category, Action<string, string> write)
	{
		_traceSwitch = traceSwitch;
		_write = m => write(m, category);
	}

	public void Debug(string message)
	{
		if (_traceSwitch.TraceVerbose)
			_write(message);
	}

	public void Info(string message)
	{
		if (_traceSwitch.TraceInfo)
			_write(message);
	}
	
	etc...
}

Testing generic methods with MbUnit

December 21, 2011Graham HayLeave a comment

Testing generic methods with different types is just as easy as anything else, with MbUnit:

[Test]
[Row(typeof(string))]
[Row(typeof(int))]
public void GenericTest<T>()
{
    GenericMethod<T>();
}

public void GenericMethod<T>()
{
    Console.WriteLine("T: {0}", typeof (T).FullName);
}

Arg<T>.Matches considered harmful?

November 10, 2011November 10, 2011Graham HayLeave a comment

I’m a fairly heavy user of RhinoMocks (although, given the choice, I’d rather use FakeItEasy).

One of my few complaints about it is the poor diagnostics when an assertion fails. One particularly dangerous combination is AssertWasCalled with Arg<T>.Matches:

public void A_test()
{
    var frobulator = MockRepository.GenerateStub<IFrobulate>();
    var cromulator = new Cromulator(frobulator);

    cromulator.Cromulate();

    frobulator.AssertWasCalled(f => f.Frobulate(Arg<Bar>.Matches(b => b.This == "something" && b.That == "somethingelse")));
}

The problem with this is that, if the assertion fails, you don’t know whether This or That (or both) was not what was expected.

One option is to assert each property separately:

public void A_slightly_better_test()
{
    var frobulator = MockRepository.GenerateStub<IFrobulate>();
    var cromulator = new Cromulator(frobulator);

    cromulator.Cromulate();

    frobulator.AssertWasCalled(f => f.Frobulate(Arg<Bar>.Matches(b => b.This == "something")));
    frobulator.AssertWasCalled(f => f.Frobulate(Arg<Bar>.Matches(b => b.That == "somethingelse")));
}

Alternatively, you can use Do to capture the object you want to inspect and then assert normally:

public void A_slightly_different_test()
{
    var frobulator = MockRepository.GenerateStub<IFrobulate>();
    Bar bar = null;
    frobulator.Stub(f => f.Frobulate(Arg<Bar>.Is.Anything))
        .Do((Func<Bar, string>)(b => { bar = b; return ""; }));
    var cromulator = new Cromulator(frobulator);

    cromulator.Cromulate();

    Assert.That(bar, Is.Not.Null);
    Assert.That(bar.This, Is.EqualTo("something"));
    Assert.That(bar.That, Is.EqualTo("somethingelse"));
}

And yes, both options are very ugly! Of course, what you should really do is use a custom matcher :)

Using NHamcrest with NUnit or XUnit

October 8, 2011Graham Hay4 Comments

NHamcrest is supported out of the box with MbUnit, but there’s nothing stopping you using it with any other framework.

You just need to write the shim code, i.e. Assert.That.

For example, with NUnit it would look something like this:

public static void That<T>(T actual, IMatcher<T> matcher, string message, params object[] args)
{
	if (matcher.Matches(actual))
		return;
	
	var writer = new TextMessageWriter(message, args);

	WriteExpected(matcher, writer);

	WriteActual(actual, matcher, writer);

	throw new AssertionException(writer.ToString());
}

private static void WriteExpected(ISelfDescribing matcher, TextWriter writer)
{
	writer.Write(TextMessageWriter.Pfx_Expected);
	var description = new StringDescription();
	matcher.DescribeTo(description);
	writer.Write(description.ToString());
	writer.WriteLine();
}

private static void WriteActual<T>(T actual, IMatcher<T> matcher, TextWriter writer)
{
	writer.Write("  But ");
	var mismatchDescription = new StringDescription();
	matcher.DescribeMismatch(actual, mismatchDescription);
	writer.Write(mismatchDescription.ToString());
	writer.WriteLine();
}

For XUnit:

public static void That<T>(T actual, IMatcher<T> matcher)
{
	if (matcher.Matches(actual))
		return;

	var description = new StringDescription();
	matcher.DescribeTo(description);

	var mismatchDescription = new StringDescription();
	matcher.DescribeMismatch(actual, mismatchDescription);

	throw new MatchException(description.ToString(), mismatchDescription.ToString(), null);
}

public class MatchException : AssertActualExpectedException
{
	public MatchException(object expected, object actual, string userMessage) : base(expected, actual, userMessage)
	{
	}
}

And, for completeness, here’s the MbUnit version:

        public static void That<T>(T item, IMatcher<T> matcher, string messageFormat, params object[] messageArgs)
        {
            AssertionHelper.Verify(() =>
            {
                if (matcher.Matches(item))
                    return null;

                var description = new StringDescription();
                var mismatchDescription = new StringDescription();

                matcher.DescribeTo(description);
                matcher.DescribeMismatch(item, mismatchDescription);

                return new AssertionFailureBuilder("Expected " + description)
                    .SetMessage(messageFormat, messageArgs)
                    .AddLabeledValue("Expected", description.ToString())
                    .AddLabeledValue("But", mismatchDescription.ToString())
                    .ToAssertionFailure();
            });           
        }

The downside of SystemTime

September 29, 2011September 28, 2011Graham Hay1 Comment

I’ve always been a fan of the elegance of Ayende’s SystemTime approach to dealing with time in tests. Unfortunately, I’ve recently re-discovered the problems that come with using globals.

I had a dependency on two different projects, each of which declared their own instance of SystemTime. Not insurmountable, as they were namespaced, but annoying and confusing nonetheless.

So from now on, for me, the new One True Way is just to pass in a Func<DateTime> as a constructor dependency:

public class Frobulator
{
    public Frobulator(Func<DateTime> currentTime)
    {
        this.currentTime = currentTime;
    }

    public DateTime Frobulate()
    {
        return currentTime();
    }
}

[TestFixture]
public class FrobulatorTests
{
    [Test]
    public void Frobulator_should_use_current_time()
    {
        var juanRodriguezCabrilloDiscoversCaliforniaAtSanDiegoBay = new DateTime(1542, 9, 28);
        var frobulator = new Frobulator(() => juanRodriguezCabrilloDiscoversCaliforniaAtSanDiegoBay);

        var dateTime = frobulator.Frobulate();

        Assert.That(dateTime, Is.EqualTo(juanRodriguezCabrilloDiscoversCaliforniaAtSanDiegoBay));
    }
}

Is the “object mother” pattern a test smell?

September 26, 2011Graham Hay2 Comments

The Object Mother is a popular testing pattern, mostly used as a factory during test setup. It allows the creation of nice DSLs, making it easy to build complex objects during test set up (leaving DRY tests, always a good thing!).

Unfortunately, I’ve recently started to see it as more and more of a test “smell”. Especially when unit testing.

I find people use it to brush an oversized test setup under the carpet. Rather than listening to their tests, and fixing the code, they use a builder to hide the size and complexity of the setup required.

I’ve noticed it particularly in combination with AutoMapper (an excellent tool, and certainly not to blame for it’s misuse). And the use of the static Mapper methods which, sadly, most of the examples use.

Because the mapper requires a realistic object, else it will throw, you end up needing to set a lot of properties on parameter objects passed in.

In this case, the solution is obvious. Break the coupling between your code & the mapper. Wrap the mapping calls in an interface (whether you use IMappingEngine, or roll your own), and mock them.

This gets you back to a true unit test, rather than combining the complexity of the mapping code with the class you’re trying to test.

So should we abandon the Object Mother?

Certainly not. It’s an incredibly useful tool, particularly when writing acceptance tests, where the complexity is a necessary evil.

But make sure you’re using it for the right reason, not taking the easy way out.

Assert.Throws with NHamcrest

February 22, 2011Graham HayLeave a comment

NHamcrest is a C# port of Hamcrest, a popular matching library. I recently added support for Assert.Throws:

    [Test]
    public void Throws()
    {
        Assert.That(() => { throw new ArgumentNullException(); }, 
            Throws.An<ArgumentNullException>());

        // with a predicate
        Assert.That(() => 
            { 
                throw new ArgumentNullException("message", new Exception()); 
            }, Throws.An<ArgumentNullException>()
            .With(e => e.Message == "message" && e.InnerException.GetType() == typeof(Exception)));
    }