Set up coverage filters
Sometimes, you may need to limit the scope of coverage analysis. For example, this makes sense if you participate in development of a large application with multiple projects and thousands of tests. In this case, you don't need to analyze coverage of all projects (types, type members) in the solution but only of those that are related to a particular feature. Another example is reducing the "noise" of a coverage tree by excluding the nodes (namespaces, classes, methods) you're not currently interested in. In all such cases, you should apply coverage filters.
- Runtime coverage filters
dotCover applies these filters during a coverage session. Use these filters to exclude unnecessary code from analysis and reduce coverage session time.
You can specify runtime coverage filters using dotCover settings or by adding comments to the source code.
- Filters of coverage results
dotCover applies these filters to coverage results (coverage tree) after the coverage session is over. Use them to exclude nodes you don't want to see at the moment. Learn more
Specify runtime coverage filters in dotCover settings
Using the dotCover settings, you can specify the runtime coverage filters for a specific namespace, project, type, type member, or attribute.
As filters are applied in runtime, dotCover does not include the filtered items into the coverage snapshot and does not show them in the Coverage Results Browser window or in the Unit Test Coverage window .
Add a runtime coverage filter
Open the filter settings page in the ReSharper settings:.
In Runtime coverage filters, click Add ... next to the required filter rule:
Analyze code only in: Specify an assembly, a class, and/or a method to be included in the coverage analysis. All other code items will be excluded. Code items are filtered independently on one another. For example, you can specify a method and leave asterisks
*for assembly and class to include only methods with the specified name from all assemblies and all classes.
Do not analyze code in: Specify an assembly, a class, and/or a method to be excluded from the coverage analysis. Code items are filtered independently on one another.
Do not analyze code marked with attributes: Specify the fully qualified attribute class name that will be used to exclude symbols from the coverage analysis. For example,
You can use asterisk wildcards when specifying code item names in a filter:
*(asterisk) represents zero or more characters.
For example, you can use the
*.Testswildcard in Do not analyze code in to exclude all test projects from code analysis.
Click Save to save the filter settings and apply your modifications.
Exclude system and non-solution assemblies from application coverage analysis
When performing coverage analysis of applications, you have additional filters for non-solution and system assemblies in the Filtering options:
(Recommended) If you are going to analyze coverage only for assemblies in your solution, select both Exclude system assemblies and Exclude non-solution assemblies. This will make coverage analysis faster.
If you are going to analyze coverage for assemblies from several solutions at once, clear Exclude non-solution assemblies.
If you want to analyze coverage in system assemblies, clear Exclude system assemblies.
Share runtime coverage filters
Solution-wide filters are saved in the Solution team-shared settings layer and, therefore, can be shared within other developers who work on this solution.
In fact, all you need to do to share solution-wide filters is to put the [SolutionName].sln.DotSettings file in your solution folder under a version control system (VCS). As soon as other team members get this file from VCS the filters will be applied on their computers as well.
Note that other JetBrains products that integrate into Visual Studio may store their solution-wide team-shared settings in the same file. Therefore, if you put this file under VCS, bear in mind that other product's settings may be shared as well. For more information, see Manage and share dotCover settings.
Specify runtime coverage filters in source code
Another way to specify a runtime coverage filter is by adding comments to the source code. This lets you exclude a particular parts of the code from coverage analysis.
Exclude particular code from coverage analysis
In your project, add a reference to the JetBrains.dotCover.MSBuild NuGet package. This is a development-only dependency that will not be included as a runtime dependency in your project.
Comment the code you want to exclude from analysis. The following comments are supported:// dotcover disable var a = 1; var b = 10; // dotcover enable /* dotcover disable */ var c = 1; /* dotcover enable */ var d = 1; // dotCover disable this line // dotcover disable next line var e = 100;
Specify filters of coverage results
dotCover applies these filters to coverage results after a coverage session is over. Use these filters to:
Exclude nodes (namespaces, classes, and so on) you're currently not interested in from the Unit Test Coverage.
Exclude an entire file from the Unit Test Coverage. For example, this may be helpful if you want to exclude some auto-generated files (that is, classes and methods declared in these files) from the results.
Exclude a node (namespace, class, class member) from coverage results
Open coverage results either in the Coverage Results Browser window or Unit Test Coverage window.
Select a node and in the context menu choose:
Exclude from Coverage Results to exclude the node from the current results.
Exclude and Create Runtime Coverage Filter to exclude the node from the results and create a corresponding runtime filter that will prevent collecting coverage data for this node in future coverage sessions.
Exclude All But This to leave only the selected node in the coverage tree.
Show the excluded nodes back
Click the Show all nodes link on top of the Coverage Results Browser window or Unit Test Coverage window .
Exclude a file from coverage results
Open filtering settings using the main menu.
Find the Exclude file masks list.
Click to add a new exclude filter for specific file masks.
You can use Ant-style wildcards in file masks:
?to match a single character excluding directory separators
*to match zero or more characters excluding directory separators
**to match any number of characters including directory separators
\to match directory separators regardless of the OS path format
For example a pattern
**Test?\**.*will match the following files: