Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How can I avoid large multi-step unit tests?

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?

like image 250
David Rubin Avatar asked Dec 05 '25 06:12

David Rubin


2 Answers

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.

like image 160
Esko Luontola Avatar answered Dec 08 '25 06:12

Esko Luontola


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.

like image 43
Steve Freeman Avatar answered Dec 08 '25 05:12

Steve Freeman



Donate For Us

If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!