How can I avoid large multi-step unit tests?

Question

I'm trying to unit test a method that performs a fairly complex operation, but I've been able to break that operation down into a number of steps on mockable interfaces like so:

public class Foo
{  
    public Foo(IDependency1 dp1, IDependency2 dp2, IDependency3 dp3, IDependency4 dp4)
    {
        ...
    }

    public IEnumerable<int> Frobnicate(IInput input)
    {
        var step1 = _dependency1.DoSomeWork(input);
        var step2 = _dependency2.DoAdditionalWork(step1);
        var step3 = _dependency3.DoEvenMoreWork(step2);
        return _dependency4.DoFinalWork(step3);
    }

    private IDependency1 _dependency1;
    private IDependency2 _dependency2;
    private IDependency3 _dependency3;
    private IDependency4 _dependency4;
}

I'm using a mocking framework (Rhino.Mocks) to generate mocks for purposes of testing, and structuring the code in the fashion shown here has been very effective thus far. But how do I unit test this method without having one big test that needs every mock object and every expectation set every time? For example:

[Test]
public void FrobnicateDoesSomeWorkAndAdditionalWorkAndEvenMoreWorkAndFinalWorkAndReturnsResult()
{
    var fakeInput = ...;
    var step1 = ...;
    var step2 = ...;
    var step3 = ...;
    var fakeOutput = ...;

    MockRepository mocks = new MockRepository();

    var mockDependency1 = mocks.CreateMock<IDependency1>();
    Expect.Call(mockDependency1.DoSomeWork(fakeInput)).Return(step1);

    var mockDependency2 = mocks.CreateMock<IDependency2>();
    Expect.Call(mockDependency2.DoAdditionalWork(step1)).Return(step2);

    var mockDependency3 = mocks.CreateMock<IDependency3>();
    Expect.Call(mockDependency3.DoEvenMoreWork(step2)).Return(step3);

    var mockDependency4 = mocks.CreateMock<IDependency4>();
    Expect.Call(mockDependency4.DoFinalWork(step3)).Return(fakeOutput);

    mocks.ReplayAll();

    Foo foo = new Foo(mockDependency1, mockDependency2, mockDependency3, mockDependency4);
    Assert.AreSame(fakeOutput, foo.Frobnicate(fakeInput));

    mocks.VerifyAll();
}

This seems incredibly brittle. Any change to the implementation of Frobnicate causes this test to fail (like breaking down step 3 into 2 sub-steps). It's an all-in-one sort of thing, so trying to use multiple smaller tests isn't going to work. It starts to approach write-only code for future maintainers, myself included next month when I've forgotten how it works. There has to be a better way! Right?

Answer 1

BDD attempts to address this problem with inheritance. If you get used to it, it's really a cleaner way to write unit tests.

A couple good links:

• link
• link
• link
• link

Problem is that BDD takes a while to master.

A quick example stolen from the last link (Steve Harman). Notice how there's only one assertion per test method.

using Skynet.Core

public class when_initializing_core_module
{
    ISkynetMasterController _skynet;

    public void establish_context()
    {
        //we'll stub it...you know...just in case
        _skynet = new MockRepository.GenerateStub<ISkynetMasterController>();
        _skynet.Initialize();
    }

    public void it_should_not_become_self_aware()
    {
        _skynet.AssertWasNotCalled(x => x.InitializeAutonomousExecutionMode());
    }

    public void it_should_default_to_human_friendly_mode()
    {
        _skynet.AssessHumans().ShouldEqual(RelationshipTypes.Friendly);
    }
}

public class when_attempting_to_wage_war_on_humans
{
    ISkynetMasterController _skynet;
    public void establish_context()
    {
        _skynet = new MockRepository.GenerateStub<ISkynetMasterController>();
        _skynet.Stub(x => 
            x.DeployRobotArmy(TargetTypes.Humans)).Throws<OperationInvalidException>();
    }

    public void because()
    {
        _skynet.DeployRobotArmy(TargetTypes.Humans);
    }

    public void it_should_not_allow_the_operation_to_succeed()
    {
        _skynet.AssertWasThrown<OperationInvalidException>();
    }
}

Answer 2

Test each implementation of IDependencyX in isolation. Then you will know that each individual step of that process is correct. When testing them individually, test every possible input and special condition.

Then do an integration test of Foo, using the real implementations of IDependencyX. Then you will know that all the individual parts are plugged together correctly. It's often enough to just test with one input, because you are only testing simple glue code.

Answer 3

Are the dependencies also dependent on each other, by having to call them in that exact sequence? If that's the case, you are really testing a controller flow, which is not the actual purpose of Unit Testing.

For example, if your code example was software for a GPS, you are not testing the actual functions, like navigating, calculating correct routes etc, but instead that a user can turn it on, enter some data, display routes, and turn it off again. See the difference?

Focus on testing the module functionality, and let a higher-level program or quality assurance tests do what you were trying to do in this example.

Answer 4

Lots of dependencies suggest that there are intermediate concepts lying implicit in the code, so perhaps some of the dependencies can be packaged up and this code made simpler.

Alternatively, perhaps what you've got is some kind of chain of handlers. In which case, you write unit tests for each link in the chain, and integration tests to make sure they all fit together.