NCover 4 has a robust set of filtering mechanisms that provide for both pre-coverage filtering and post-coverage filtering. The significant difference between the two is that a pre-coverage filter prevents code profiling and data collection for items eliminated by the pre-coverage filter. The post-coverage filter provides modified views and aggregations of the collected data and allow the user to decide what data is important to him at the time the data is queried from the data store.
Advantages to Pre-Coverage Filtering
The most significant advantage to pre-coverage filtering is to reduce the amount of work required by the server to profile an application. Most .Net code has more than a few modules which are incorporated by the framework whose coverage numbers are not germane to the quality of code being produced by my team. Thankfully NCover has a predefined list of most system based assemblies that it automatically excludes for every project. For those assemblies it doesn’t assume are system assemblies, I can create exclusion rules which will eliminate this coverage overhead; reducing both the profiling load and the storage of data.
Pre-coverage filters are created in the project definition and can be added and modified in the project configuration dialog (figure 1).
figure 1.
Advantages of Post-Coverage Filters
Once my coverage collection is lean and mean as a result of my pre-coverage filters, I can then leverage post-coverage filters to focus my data mining efforts. This is especially useful for my team when we have divided areas of focus. Post-coverage filters utilize the same coverage set for all areas of my team, but provide a view tuned to display the code for which a particular developer or technician may have responsibility. This is also useful for us in short term sprints as we direct our focus to the coverage of a single module on a build by build iteration, we can create a trend dashboard for that module with one simple filter.
Post-coverage filters are defined with the data views of a project. The left panel of the data view in NCover displays a list of all defined post-coverage filters for a project (figure 2). Filters can be added from this location or are inherited from Code Central projects. The edit window for post coverage filters is nearly identical to its pre-coverage cousin (figure 3).
figure 2.
Now that I know how to use the filters and why, it’s also helpful to know how the logic is interpreted. The following rules are a guideline for creating a personalized filtering strategy. It helps me to think of these rules in terms of creating a subset of data possible to collect during a coverage run. The rules then create unions or intersections depending on whether they are inclusions or exclusions. Inclusions are unioned together to create a larger set. Exclusions intersect my coverage set to take away data I don’t want to see.
No filters:
- Coverage subset is all encountered elements – the subset of everything within a process, minus the automatic exclusions.
- System-wide automatic exclusions are controlled by the “systemAssemblies” list in the ncover.exe.config
Include Rules:
- Include rules redefine the coverage subset of items to be exclusively from the inclusion list.
- Multiple include rules create a union for the coverage set.
- The existence of even a single include rule automatically excludes anything that does not match that rule.
- Include rules cascade downward to include child nodes of a module, namespace, class, or document path.
- Including a node will implicitly include the parent nodes necessary to navigate to that explicitly included node (i.e. if I include a class, the Module and Namespace are included so navigation and summary aggregation are possible).
- Since excludes are applied after Includes it is possible to exclude all data you intended to include by excluding the parent node, i.e. namespace or module or type.
Exclude Rules:
- Exclude rules subtract from the base set of data (unfiltered or inclusion set).
- Exclude rules cascade downward so that the exclude of a module would exclude all namespaces, types, and methods in that module.
- Exclude rules are applied last.
- Exclude rules subtract from the set of data created by Includes.
System Assembly exclusions take the following form in the NCover.exe.config file:
<systemAssemblies>
<assembly>accessibility.dll</assembly>
<assembly>sort.*nlp</assembly>
<assembly>msvc[mrp].*</assembly>
<assembly>mscorcfg.*</assembly>
<assembly>mscorlib.*</assembly>
<assembly>sysglobl.*</assembly>
…. etc. …
</systemAssemblies>