I have long been a disciple of what is sometimes known as the “London school” of TDD (or “outside in” design), but I like to think I’m open to alternatives, when proven useful.

With that in mind, I found James Shore’s testing without mocks series very interesting. While I’m not quite ready to dive in at the deep end of that approach, one of the reasons to mock your dependencies (other than avoiding IO) is to remove the complexity from your tests, and James offers a handy alternative.

beforeEach(function() {
    dep1 = sinon.stub().resolves();
    ...
    handler = new Handler(dep1, dep2, dep3);
});

Rather than using [insert favourite mocking library] to represent those dependencies, and risking the slippage that can occur when the real version changes, but the tests are not updated (if you haven’t got contract tests for everything); you can use the real object (ideally, some pure “business” function) both in the set up, and also in your assertions, as a “test oracle“.

beforeEach(function() {
    dep1 = new Dep1();
    ...
});

it("should return the expected flurble", function() {
    ...
    const res = await handler.handle(req);

    expect(res.flurble).to.equal(dep1.bar(req.foo));
});

This way, if the implementation of the dependency changes, the test should still pass; unless it would actually affect the SUT.

I’m sure this approach comes with its own tradeoffs, and won’t help you with anything other than simple dependencies, but it can be useful in situations where you would like to use the real dependency and still keep the tests relatively simple.

(This is probably another force pushing in the direction of a ports and adapters architecture (or impure-pure sandwich), allowing you to use “sociable” tests in the kernel, and narrow integration tests at the edges.)

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));
    }
}

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.