Coverage Filters in dotCover
Wednesday, May 29th, 2013Using 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:
For additional information about configuring the console runner, please refer to web help. Additional filter examples can be found in the web help as well.
