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…
5 Comments
There is one trick you can do to get rid of the dependency. If you make use of a CommonAssemblyInfo.cs file linked between your projects, then define the attribute in there (preferably without a namespace). That way you have no references and no using statements to add.
The potential for abuse is a good point. An idea I have for NCoverExplorer in the future is an “exclusions” report. That way you can quickly see everything that has had the attribute applied at which scope. So developers who think they can stay under the radar by putting the attribute on all their classes will get caught out. Another idea for a future NCover version would be making the attribute support a string overload that allows developers to put a reason for the exclusion, which gets passed into the output for reporting.
Sorry, for got to add. If you call the attribute “CoverageExcludeAttribute”, then the TestDriven.Net add-in will automatically exclude when running your tests through it. It effectively has a hard-code //ea CoverageExcludeAttribute behind the scenes. Jamie has been holding off putting an options dialog in but when he does shortly that should make this more configurable.
Hey Grant,
Good tip.
I love the report and reason feature ideas.
Does it matter what namespace “CoverageExcludeAttribute” is in? The options dialog would be ideal.
Hi Dave - yes the namespace does matter (i.e. that there is none) for the TD.Net trick to work. Hence why putting it in an AssemblyCommonInfo.cs file works quite nicely. It’s because that argument is hard-coded as //ea CoverageExcludeAttribute. As I posted above hopefully Jamie can parameterise that in some way in the future for people who do want a different name or want it in a namespace.
Hi Kiwidude,
Do you have any idea to take the coverage for webservices.. I have unittests for webservices.. Using NCover.Explorer is it possible to take the coverage report(Funtion and line coverage) ..
Note: I am able to take the coverage reports for dlls(assemblies).
Thanks
Siva
Post a Comment