Coverage Filters in dotCover
Using dotCover, we can run coverage analysis on our code. We can verify which portions of our project are covered by unit tests and which are not. However, there are times when we don’t want to perform analysis on our entire project and instead want to target certain areas. This can be because we want our coverage analysis to run faster or because we want to exclude third-party or obsolete assemblies or classes from the resulting report.
Let’s have a look at how we can setup coverage filters using Visual Studio. Since dotCover also comes with a console runner, we’ll have a look at setting up coverage filters there as well.
Filtering coverage in Visual Studio
In the screenshot below, we can see test and code coverage results after running all unit tests for the Nancy framework. Code coverage has been run for all projects we’ve been testing, but also for our unit test assemblies themselves!
We can filter the test assemblies out by using Coverage Filters. Using the dotCover | Edit Coverage Filters… menu or the keyboard shortcut Ctrl+Alt+K, Ctrl+Alt+F, we can manage Coverage Filters. By default, dotCover already filters out code marked with the System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute attribute, but let’s add an additional filter using the Add filter toolbar button.
In the Add Coverage Filter dialog, we can specify which code should be analyzed or excluded from analysis. We can configure this based on several rules:
- Based on a filter string which can match assembly names, class names and method names. Using these, we have fine-grained filter capabilities available. Note that class names and method names can contain wildcards as well, which means we can filter out certain namespaces or filter out method names that start or end in a given pattern.
- Based on an attribute. We can use existing attributes (e.g. ObsoleteAttribute) as well as our own attribute. For example, we can create a DontCoverThisAttribute and use it throughout our codebase and let dotCover exclude all code marked with this attribute.
Since we want to exclude test assemblies from coverage and all our test assemblies have a name ending in .Tests, we can specify a filter using a wildcard pattern, as you can see in the image below.
Filters can be defined in different scopes:
- All solutions, applying filters to all solutions on our computer
- Current solution, specifying the filter should only be applied on the current solution
After clicking Ok, our filter will be applied during our next code coverage analysis run. As you can see from the next image, code coverage analysis has not been run on our unit test assemblies.
Note that coverage filters only tell the dotCover engine to not analyze code which matches a filter rule, it does not exclude the assemblies from the coverage report. If we want to completely hide the test assemblies from the results, we can right-click the tests node and use the Exclude selected node context menu.
For additional information about using dotCover’s filters please check the web help.
Filtering coverage with the console runner
In the screenshot below, we can see an XML report of code coverage analysis running on a number of unit tests in the Nancy framework. Code coverage has been run for many assemblies, apparently even including the test assemblies themselves!
To filter out these test assemblies, we can specify filters in our coverage configuration file, coverage.xml. Just like we can do in Visual Studio, the configuration file supports adding various filters types:
- Include specific assemblies, classes or methods by listing them as childs of the IncludeFilters element
- Exclude specific assemblies, classes or methods by listing them as childs of the ExcludeFilters element
- Exclude code marked with a given attribute, by listing them in the AttributeFilters element
Let’s add a filter which uses a wildcard pattern to exclude all assemblies with the word “Test” in their name from coverage analysis:
During our next coverage analysis run, the specified filter(s) will be applied. As a result, our XML report will no longer contain information about assemblies that were excluded using filters:
Subscribe to Blog updates
Thanks, we've got you!
Eager, Lazy and Explicit Loading with Entity Framework Core
Entity Framework Core (EF Core) supports a number of ways to load related data. There’s eager loading, lazy loading, and explicit loading. Each of these approaches have their own advantages and drawbacks. In this post, let’s have a quick look at each of these ways to load data for navigational prope…
OSS Power-Ups: bUnit – Webinar Recording
The recording of our webinar, OSS Power-Ups: bUnit, with Egil Hansen and Steven Giesel, is available. This was the twelfth episode of our OSS Power-Ups series, where we put a spotlight on open-source .NET projects. Subscribe to our community newsletter to receive notifications about future webi…
Accelerating Your Testing Workflow with Unit Test Creation and Navigation
Unit tests play an important role in our daily development workflow. They help us ensure our codebase's correctness when writing new functionality or performing refactorings to improve readability and maintainability. In the process, we often create new test files that accompany the p…
Introducing Predictive Debugging: A Game-Changing Look into the Future
With the introduction of debugging tools, software developers were empowered to interactively investigate the control flow of software programs to find bugs in live environments. At JetBrains, we've always strived to improve the art of debugging. Besides the more standard things you expect from a de…