Question

I was looking over a fairly modern project created with a big emphasis on unit testing. In accordance with old adage “every problem in object oriented programming can be solved by introducing new layer of indirection” this project was sporting multiple layers of indirection. The side-effect was that fair amount of code looked like following:

public bool IsOverdraft)
{
    balanceProvider.IsOverdraft();
}

Now, because of the empahsis on unit testing and maintaining high code coverage, every piece of code had unit tests written against it.Therefore this little method would have three unit tests present. Those would check:

1. If balanceProvider.IsOverdraft() returns true then IsOverdraft should return true
2. If balanceProvider.IsOverdraft() returns false then IsOverdraft should return false
3. If balanceProvider throws an exception then IsOverdraft should rethrow the same exception

To make things worse, the mocking framework used (NMock2) accepted method names as string literals, as follows:

NMock2.Expect.Once.On(mockBalanceProvider)
    .Method("IsOverdraft")
    .Will(NMock2.Return.Value(false));

That obviously made “red, green, refactor” rule into “red, green, refactor, rename in test, rename in test, rename in test”. Using differnt mocking framework like Moq, would help with refactoring, but it would require a sweep trough all existing unit tests.

What is the ideal way to handle this situation?

A) Keep smaller levels of layers, so that those forwarding calls do not happen anymore.

B) Do not test those forwarding methods, as they do not contain business logic. For purposes of coverage marked them all with ExcludeFromCodeCoverage attribute.

C) Test only if proper method is invoked, without checking return values, exceptions, etc.

D) Suck it up, and keep writing those tests 😉

Answer 1

Either B or C. That’s the problem with such general requirements (“every method must have unit test, every line of code needs to be covered”) – sometimes, benefit they provide is not worth the cost. If it’s something you came up with, I suggest rethinking this approach. The “we must have 95% code coverage” might be appealing on paper but in practice it quickly spawns problems like the one you have.

Also, the code you’re testing is something I’d call trivial code. Having 3 tests for it is most likely overkill. For that single line of code, you’ll have to maintain like 40 more. Unless your software is mission critical (which might explain high-coverage requirement), I’d skip those tests.

One of the (IMHO) most pragmatic advices on this topic was provided by Kent Beck some time ago on this very site and I expanded a bit on those thoughts with in my blog posts – What should you test?