Repetitive code in unit-tests

Question

We find ourselves coding repetitive fixture/mock setups in many test-cases - like this case:

var fixture = new Fixture().Customize(new AutoMoqCustomization());
var encodingMock = fixture.Freeze<Mock<IEncodingWrapper>>();
var httpClientMock = fixture.Freeze<Mock<IHttpWebClientWrapper>>();
var httpResponseMock = fixture.Freeze<Mock<IHttpWebResponseWrapper>>();
var httpHeaderMock = fixture.Freeze<Mock<IHttpHeaderCollectionWrapper>>();
var etag = fixture.CreateAnonymous<string>();
byte[] data = fixture.CreateAnonymous<byte[]>();
Stream stream =  new MemoryStream(data);

encodingMock.Setup(m => m.GetBytes(It.IsAny<string>())).Returns(data);
httpHeaderMock.SetupGet(m => m[It.IsAny<string>()]).Returns(etag).Verifiable();
httpClientMock.Setup(m => m.GetResponse()).Returns(httpResponseMock.Object);
httpResponseMock.Setup(m => m.StatusCode).Returns(HttpStatusCode.OK);
httpResponseMock.SetupGet(m => m.Headers).Returns(httpHeaderMock.Object);
httpResponseMock.Setup(m => m.GetResponseStream()).Returns(stream);

As per the idea that the tests should be self-contained and readable from start to end we dont use magical Setup/Teardown methods.

Can we in any way (AutoFixture customizations, helper methods) reduce the "grunt work" of these tests?

I have read that self-contained notion and simply can't agree, or at least it should be interpreted differently. The same rules of production code maintenance should be applied to your tests. — flq, May 08 '12 at 07:01
You may find this helpful: [Keep your unit tests DRY with AutoFixture Customizations](http://megakemp.wordpress.com/2011/12/15/keep-your-unit-tests-dry-with-autofixture-customizations) — Enrico Campidoglio, May 08 '12 at 07:46

score 15 · Answer 1 · answered May 08 '12 at 08:10

15

From Growing Object-Oriented Software (GOOS) comes a piece of good advice: if a test is hard to write, it's feedback about the API of the System Under Test (SUT). Consider redesigning the SUT. In this particular example, it looks as though the SUT has at least four dependencies, which might indicate a violation of the Single Responsibility Principle. Would it be possible to refactor to Facade Services?

Another great piece of advice from GOOS is that

Mocks should only be used for Commands
Stubs should be used for Queries

In the above example it looks as though you need to do a lot of Moq Setup for methods that are really Queries. That indicates a test smell as well. Is there a Law of Demeter violation somewhere? Would it be possible to cut the method chain?

answered May 08 '12 at 08:10

Mark Seemann

225,310
48
427
736

It actually only got one depency: HttpWebRequest. But to setup the mock to mimic HttpWebRequest (which havent got any interfaces so we wrap and wrap and wrap) – svrist May 08 '12 at 08:43
Well, the HttpWebRequest API sucks for particularly that reason, but can't you encapsulate the actions you want it to perform in a (higher-level) Facade Service? – Mark Seemann May 08 '12 at 08:46
BTW, depending on which version of the BCL you're on, there are already wrappers defined for that entire API: http://msdn.microsoft.com/en-us/library/system.web.httpcontextbase.aspx IOW, there's no reason to come up with your own custom wrappers. However, that API still suffers massively from LoD violations. – Mark Seemann May 08 '12 at 08:49
Dont we end up a facade service that needs exactly the same test setup as above then? – svrist May 08 '12 at 08:57
If you do, it's not a Facade Service. The idea about a Facade is that it encapsulates some nitty-gritty implementation details in a more coarse-grained interface. You *may* still need to add Moq Setups for that service, but since it's more coarse-grained, you should be able to replace e.g. four Setups with a single Setup. – Mark Seemann May 08 '12 at 09:23
I was thinking that I then need to test the facade service class and then I need to do the Moq setup anyway. But I see your point in that I then perhaps can minimize the amount of times I need to do it somewhat – svrist May 08 '12 at 09:27
1

Yes, you'd also need to unit test the Facade, but each unit will have fewer dependencies. This will make each test simpler, as there will be fewer permutations that you'll have to worry about. This is essentially a refactoring towards polymorphism. – Mark Seemann May 08 '12 at 10:26

score 13 · Accepted Answer · answered May 08 '12 at 07:13

You can create a composite Customization that will customize the fixture by using all contained customizations.

public class HttpMocksCustomization : CompositeCustomization
{
    public HttpMocksCustomization()
        : base(
            new AutoMoqCustomization(),
            new HttpWebClientWrapperMockCustomization(),
            new HttpWebResponseWrapperMockCustomization()
            // ...
            )
    {
    }
}

Each customization can be defined as follow:

public class HttpWebClientWrapperMockCustomization : ICustomization
{
    public void Customize(IFixture fixture)
    {
        var mock = new Mock<IHttpWebClientWrapper>();
        mock.Setup(m => m.GetResponse()).Returns(httpResponseMock.Object);

        fixture.Inject(mock);
    }
}

public class HttpWebResponseWrapperMockCustomization : ICustomization
{
    public void Customize(IFixture fixture)
    {
        var mock = new Mock<IHttpWebResponseWrapper>();
        mock.Setup(m => m.StatusCode).Returns(HttpStatusCode.OK);

        fixture.Inject(mock);
    }
}

// The rest of the Customizations.

Then inside the test method you can do this:

var fixture = new Fixture().Customize(new HttpMocksCustomization());

That way, when you request a Mock instance you don't have to repeat the setup steps. The one we customized earlier will be returned:

var httpClientMock = fixture.Freeze<Mock<IHttpWebClientWrapper>>();

However, if you use xUnit.net, things can be simplified even further.

You can create an AutoDataAttribute-derived type to provide auto-generated data specimens generated by AutoFixture as an extention to xUnit.net's Theory attribute:

public class AutoHttpMocksDataAttribute : AutoDataAttribute
{
    public AutoHttpMocksDataAttribute()
        : base(new Fixture().Customize(new HttpMocksCustomization()))
    {
    }
}

Then, in your test method you can pass the Mocks as arguments:

[Theory, AutoHttpMocksData]
public void MyTestMethod([Freeze]Mock<IHttpWebClientWrapper> httpClientMock, [Freeze]Mock<IHttpWebResponseWrapper> httpResponseMock)
{
    // ...
}

Also, as Enrico points out you can read his excellent article http://goo.gl/AFmMi which describes Customizations into great detail. — Nikos Baxevanis, May 08 '12 at 08:05

Oleksi · Answer 3 · 2012-05-08T06:27:19.933

If all of your tests use this code, it should be placed in the set up/tear down methods. It's ok if your set up/tear down methods are somewhat complicated, as long as all of your unit tests are depending on it. This is certainly better than duplicating all that complicated stuff in every test. When I read a test, I know that setup and teardown are part of each test implicitly, so I don't think you lose anything in readability either. The thing to avoid is including things in setup that not every test needs. This creates confusing situations where you setup method doesn't match all your tests nicely. Ideally your set up method should apply 100% to every single test.

If the shared code is not used in all your tests, extract the shared code into helper functions.Writing good tests code is just like writing any other good code, and the same principles apply.

Repetitive code in unit-tests

3 Answers3