I was working with nCoverExplorer at work this week checking to see how diligent we’d been while writing our tests. One of our major tasks in the last month has been to refactor our service layer so that it employs constructor based dependency injection. When I looked through the coverage on this work I noticed that the coverage was lower than I’d been hoping for. Closer inspection showed that the culprit was the constructor chaining we were using as part of our Dependency Injection refactoring.
Below is an example of a class that we would create.
1 | namespace DependencyInjectionExample |
And here is an example of how we would test it.
1 | using MbUnit.Framework; |
When you run this test through nCover you get this.
Because my only test, which I believe to be the only one necessary, uses the parameterized override of the constructor, the default constructor does not get executed. In this example that means that code coverage drops from 100% to 78% which is below the threshold of 90% that I strive for. I could easily write another test that creates the object using the default constructor, but I don’t see why I’d write that test. In my mind it doesn’t bring any benefit to the test suite. I realize that code coverage metric are not metrics of quality and this is why I don’t see the benefit.
My question to all of you is this: What do you do in this situation?