flow.
"Flow is a condition of deep, nearly meditative involvement." - Tom DeMarco

Easier Exclusions in NCoverExplorer

Wednesday, June 13, 2007 9:16 AM
Don't get me wrong, code coverage is important...to an extent.  But sometimes there are just those class that you just don't care if they're covered or not.  Specifically, I'm thinking of the *.Designer.cs files that show up to hold the layout of your form controls or that contain the resources of your *.resx files.  These classes often don't have adequate coverage but, normally, as they're automatically generated I'm not too concerned about it.  However, I would like for NCoverExplorer to stop reminding me of it and recently I found a simple solution. 

I'm sure that most of you are familiar with the NCover exclude coverage attribute, if not you can find more information about it here.  Although this does work, it's always felt clunky to me.  First of all, I don't like defining attributes by name versus type and secondly I've never been crazy about altering my code for the benefit of the tool.  This is the same reason that I prefer to exclude FxCop rules in the project file rather than excluding them by code.  There are also some other alternatives such as removing the PDB files for assemblies which you don't want covered, but that also feels clunky and only works at the assembly level.  Luckily, there's a better way.

NCoverExplorer, much to my surprise, allows you to exclude reporting the coverage of certain objects based on naming conventions.   You can find this little gem in NCoverExplorer under View->Options... and then on the Exclusions tab.



You can set this exclusion at the assembly, class, or namespace level.  You can even use regular expressions!  Once you've set your exclusions the objects which you've excluded will now show up under the Excluded branch of the coverage tree.


As you can see in this example, I've excluded my actual test assemblies from coverage analysis since I'm only interested the classes under test, not the tests themselves.  Note that I could do this in the setup if launch NCoverExplorer directly, but as I usually run my coverage analysis from inside of TestDriven.NET the setup is typically bypassed for me.

Remember, this doesn't prevent the objects from having coverage analysis...only from NCoverExplorer reporting that analysis to you.  If you're interested in excluding certain objects from any analysis at all you can find plenty of MSBuild and NAnt tasks to do that for you.
kick it on DotNetKicks.com Digg!

Feedback

# re: Easier Exclusions in NCoverExplorer

Nice! So I wasn't quite clear on the TD.NET part. When running tests via TD.NET, your exclusions don't work? Is that what you're saying?

Could be a nice feature request of TD.NET. I think I'd like to specify these exclusions as a sort of config file that can live with the code. Like you, I don't want my code to reference the NCover assemblies just to exclude code. 6/22/2007 1:34 PM | Haacked

# re: Easier Exclusions in NCoverExplorer

Whatever exclusions you set in the options dialog should be applied to every coverage xml file loaded in NCoverExplorer from that point onwards. So using "Test with Coverage" in TD.Net should "reapply" the exclusions when NCoverExplorer is launched.

A future enhancement will be to have specific "project" configurations where you can configure exclusions for each "project". Once that is enabled then I would offer the next level of exclusion capability which would be at the method level, so you would not need to decorate your code with coverage exclusion attributes at all. By associating a project with a solution name for instance, then TD.Net could pass that in the command line so the NCoverExplorer gui loads the right set of exclusions...

For now though your only way to have different "sets" of exclusions is when reporting via the command line/NAnt/MSBuild tasks. To do it with the gui you would have to "maintain" (copy/replace) multiple config files for NCoverExplorer in your local settings folder - obviously not very practical.

I'll get around to adding the project stuff one day... 6/23/2007 3:48 PM | kiwidude

# re: Easier Exclusions in NCoverExplorer

Haacked,

I'm sorry, the point regarding TD.NET point probably begged a bit more explanation. When I run code coverage I typically, using TD.NET, simply right click the class in question in the editor and say "Test With->Coverage". This automatically loads the object in question into my test runner, runs the test with coverage enabled, and then reports the coverage to me in NCoverExplorer. Although this is amazingly convenient, and likely leads to my checking code coverage much more than I would otherwise, it does bypass the initial setup step in NCoverExplorer which would allow my to specify objects to be excluded right there in the configuration dialog. I like your idea regarding a config file, or maybe even a separate configuration dialog, in TD.NET which would allow me to configure the tools it uses under the hood and allow TD.NET to simply pass the config options right down into NCoverExplorer. 6/25/2007 8:21 AM | Jeremy

# re: Easier Exclusions in NCoverExplorer

Hmm, after reading KiwiDude's comment it looks like l was mistaken. I had assumed that the exclusions were working from that point on simply because I had set the exclusions in the NCoverExplorer window. I hadn't realized that TD.NET would continue to use those settings from there on. Though in hindsight I suppose it makes sense that was what was happening.

And I would say it's a safe bet that KiwiDude would probably know :)

Thanks for the info KiwiDude. 6/25/2007 8:25 AM | Jeremy

# re: Easier Exclusions in NCoverExplorer

No problem Jeremy. If only there was a help manual, eh?

To clarify for anyone who reads my blog comment above and is still confused. NCoverExplorer maintains a single configuration file, stored in your local documents and settings folder. This will be used by all NCoverExplorer.exe instances on your machine - regardless of whether launched by TD.Net or just running the gui manually. Your coverage exclusions you configure via the options dialog get stored in there along with the other things like colours, thresholds etc. Hence that is why I say whatever exclusions you apply in the options dialog will get "remembered" for every time you launch the gui after that.

The console application otoh has a command line argument allowing you to specify a configuration file, which can contain your own set of exclusions. Similarly the NAnt/MSBuild tasks can either be passed a config file or be configured with exclusions in the xml.

It's a starting point that is good enough for most usages... Enjoy! 6/28/2007 6:41 PM | kiwidude

Post a comment





 

Please add 5 and 8 and type the answer here: