Comments on: Using Attributes to Exclude Code from Coverage http://laribee.com/blog/2007/04/05/using-attributes-to-exclude-code-from-coverage/ Coaching, Process, Design, Speculation Sat, 22 Nov 2008 07:01:03 +0000 http://wordpress.org/?v=2.6.3 By: siva http://laribee.com/blog/2007/04/05/using-attributes-to-exclude-code-from-coverage/#comment-31032 siva Mon, 27 Aug 2007 06:10:17 +0000 http://laribee.com/blog/2007/04/05/using-attributes-to-exclude-code-from-coverage/#comment-31032 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 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

]]> By: kiwidude http://laribee.com/blog/2007/04/05/using-attributes-to-exclude-code-from-coverage/#comment-4641 kiwidude Thu, 19 Apr 2007 19:48:42 +0000 http://laribee.com/blog/2007/04/05/using-attributes-to-exclude-code-from-coverage/#comment-4641 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 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.

]]> By: Dave http://laribee.com/blog/2007/04/05/using-attributes-to-exclude-code-from-coverage/#comment-3905 Dave Sun, 08 Apr 2007 02:20:10 +0000 http://laribee.com/blog/2007/04/05/using-attributes-to-exclude-code-from-coverage/#comment-3905 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. 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.

]]> By: kiwidude http://laribee.com/blog/2007/04/05/using-attributes-to-exclude-code-from-coverage/#comment-3846 kiwidude Sat, 07 Apr 2007 10:22:29 +0000 http://laribee.com/blog/2007/04/05/using-attributes-to-exclude-code-from-coverage/#comment-3846 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. 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.

]]> By: kiwidude http://laribee.com/blog/2007/04/05/using-attributes-to-exclude-code-from-coverage/#comment-3845 kiwidude Sat, 07 Apr 2007 10:20:41 +0000 http://laribee.com/blog/2007/04/05/using-attributes-to-exclude-code-from-coverage/#comment-3845 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. 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.

]]>