What to consider in Unit test coverage?

Question

I have a C# Entity Framework project with Data, Data Access and Service components. The Config admin has enabled code coverage(Sonarqube) that currently shows 0% coverage for Data and data access components.

1) Although the MSTest unit test code written for Service component's class method is doing something like --> Student s = new Student() (Student is a public class in Data component) I presume it won't be accounted for as a covered line for Data component? I verified that even writing a dummy test to check if invoking the constructor in a new testmethod it still marking the logicless data class Student as not covered. Is this expected ?

2) The Entity framework data component has virtually no business logic as it only has fluent api configuration classes, repositories and unit of work classes that don't do any logic on their own and rely on base implementation. And it seems obvious to me that one can't unit test the Data Access component as well.

With the above said points, would I be correct to ask the config team to exclude Data and Access components from participating in code coverage metrics ?

Answer 1

I cannot speak for the technologies you mention, especially given you don't mention what language the code is written in. My experience is with Java, Objective-C and Swift.

In my experience, obtaining 80%+ code coverage is not too hard. Especially if you can apply a good mocking framework to assist with your test cases.

If your test coverage tool is telling you that you have 0% coverage despite the execution of a constructor, then I would suggest one of two things. Either the class involved is not being instrumented by the coverage tool and therefore is not tracking the executions, or the tool is not giving you good results.

The first problem can be solved by ensuring that all classes are being instrumented correctly. The second problem can be solved by ditching your coverage tool and getting a better one.

Ignoring classes is a false economy. It's like claiming you've finished vacuuming the house because you're excluding the rooms you didn't use this week. You haven't really finished and those rooms still need a vacuum.

Answer 2

The rule in TDD is "Test everything that could possibly break" Can a getter break? Generally not, so I don't bother to test it. Besides, the code I do test will certainly call the getter so it will be tested.

Junit test for POJO - > This link describes whether the POJO's to be tested or not !

Ground rule, everything to be tested in a code base. But there would be exceptions with POJO and auto generated code base.

In such scenarios, this depends with the team that accepts the reports. Using Exclude from Sonar link, we can exclude the modules.

1. I presume it won't be accounted for as a covered line for Data component? 

Depends on the team that accounts the reports. How ever there are open libraries to check these. Pojo testing library

2. The Entity framework data component has virtually no business logic...

No point in unit testing where there is no business logic. In such cases, use the methods to skip from sonar.

PS: As it is not mentioned about the language that you use, made it generic for Java - sonar - maven environment.