I have this little assembly I’m working on which takes uses HttpModule approach to managing an NHibernate ISession. It’s written test first and I’ve isolated all of the ASP.NET and NHibernate ”gunk” into one class that inherits a mockable interface. Great – I can interaction and state test the heck out of it and all’s right with the world for the most part.
I’ve got pretty good coverage (despite my mixed feelings on the code coverage metric) on the library but, still, there’s this one class with nothing but HttpContext this and HttpApplication that. That and the HttpModule itself has a dependency on HttpContext.
Wouldn’t it be great if I could ignore those parts when running NCover? Sure you can use NCoverExplorer to tick off the various classes and members you don’t care about, but there’s got to be a better way, especially when it comes to automated builds.
Turns out there’s a switch on the NCover console app, appropriately named ncover.console.exe. The switch is //ea. I presume it stands for “Exclusion Attribute” or “Excluded Attribute” or some such thing. Anyway, you can build a simple attribute that you can toss on various bits of code (anywhere you’d normally put an attribute) and NCover will exclude that member/class/assembly/whatever from it’s coverage report.
I made a class library project with a single in it called “NoCoverageAttribute” that looks something like this:
using System; namespace TestHelper { [AttributeUsage(AttributeTargets.All)] public class NoCoverageAttribute : Attribute {} }
Apply the attribute to the various classes and members in your code then run NCover from the command line like so:
C:\>ncover.console nunit-console MyTestAssembly.dll //ea TestHelper.NoCoverageAttribute
Voila! Code with the attribute is automatically excluded and your coverage number now becomes “percent of code I want covered that’s covered.” Nice but I see a couple of caveats.
I’m not 100% sure if I mind the extra dependency no matter how small, but I’ll live with it for now. I also see a potential for abuse; excluding stuff could easily be abused if not understood or practiced sensibly. When employing a tactic like this we’ll do well to remember the guiding wisdom of Uncle Ben Parker…

GitHub
LinkedIn
Twitter
{ 1 trackback }
Comments on this entry are closed.