Recently I blogged about how to generate nice code coverage reports for ASP.NET Core and .NET Core applications. This blog post focuses on how to leave out from code coverage all code that will not be covered with unit tests and get numbers shown on code coverage reports correct.
What to exclude from code coverage?
I think almost all applications have some classes we don’t want to test. Usual candidates are primitive models and Data Transfer Objects (DTO). One example is here.
public class EditFolderModel
{
public int Id { get; set; }
public string Title { get; set; }
public int? parentFolderId { get; set; }
}
Without any additional information these classes will be part of code coverage calculations.
Excluding code from code coverage
The easiest way to exclude code from code coverage analysis is to use ExcludeFromCodeCoverage attribute. This attribute tells tooling that class or some of its members are not planned to be covered with tests. EditFormModel class shown above can be left out from code coverage by simply adding the attribute.
[ExcludeFromCodeCoverage]
public class EditFolderModel
{
public int Id { get; set; }
public string Title { get; set; }
public int? parentFolderId { get; set; }
}
ExcludeFromCodeCoverage attribute works also on class member level.
public class ErrorViewModel
{
[ExcludeFromCodeCoverage]
public string RequestId { get; set; }
public bool ShowRequestId => !string.IsNullOrEmpty(RequestId);
}
ExcludeFromCodeCoverage attribute in action
I take my simple demo application and generate code coverage report for it. There’s no code excluded – everything is counted in.
Now I add ExcludeFromCodeCoverate attribute to all classes and members that doesn’t need testing. After this I generate new report.
I left out load of primitive models, DTO-s, constructors and scaffolded ASP.NET Identity code-behind files. As a result the numbers on my code coverage report changed around 50 percent and that’s huge even for small web application.
Should I use ExcludeFromCodeCoverage attribute?
I think it makes a lot of sense to exclude from code coverage reports the code that will never be covered with tests by us. Reports above were generated to relatively small web application and change in numbers was pretty big. I don’t want to say that same effects appear with every application but there will be changes in numbers.
Over time these metrics may be important part of estimating the need for unit tests. If these numbers lie then the work ahead may seem way bigger than it actually is. This is why it is important to keep these metrics correct.
Wrapping up
Although code coverage reports are easy to set up there’s still some work needed to get numbers right. On .NET we can use ExcudeFromCodeCoverage attribute to leave out whole classes and structs or members like methods, properties, constructors and events. As example reports show then corrections to code coverage numbers can be significant.
View Comments (4)
Is there a sensible way to exclude code from coverage at runtime based on operating system? I have some interop code which differs between Windows and Linux at runtime. I don't want to have two versions of the assembly - so I can't use a compile time switch. Thanks.
I think there's no nice way to do it. First thing that comes to my mind are builds targeting specific platform and using #if #endif directives to check if build is for Linux or Windows. You can apply this trick just for code coverage reports and do usual build with no conditionals independently.
Hi, thanks for the reply. Yup, that's what I thought and I'll think about that. It also occurred to me that it might be saner to just build once, but run the coverage tests on all platforms and combine the results into one report. I think that's doable.
is there any way to exclude whole assemblies? like ones containing generated EF code.