Option to Ignore certain classes

UI components are hard to test (even when using tools such as NUnitForms) and have limited value if decoupled correctly from controller code (aka Humble Dialog Box) and no conditional logic exists. So I would like a way to ignore certain classes from the coverage report and to be able to say that I have a certain percent coverage excluding the UI for example.

I guess I could probably mess around with the XSL file to do this but I'm not fond of XSL.

Re: Option to Ignore certain classes

This is a feature that has been suggested quite a lot and I plan to introduce it before release. Thanks for the suggestion!

Re: Option to Ignore certain classes

I've added the first shot at this. You can now specify attributes that mark code to be excluded from coverage. There is more to do, but I wanted to get it out for users to check out.

Re: Option to Ignore certain classes

I have some facade style classes that are made up entirely of static methods.

I mark these as not inheritable, and put a private constructor in each one, so that it can't accidently be instantiated.

However, the constructors always show up as untested, which is by design from my point of view.

In light of what you're looking at doing/going to be doing in terms of letting us flag things for coverage exclusion, what do you think the best way will be to handle this specific situation? Will I have to put an attribute on each one, or is the situation uniquely identifable enough that it could be handled automatically?

Re: Option to Ignore certain classes

There are a couple of ways that this could be handled. One of the ways is with an attribute. Another way is by using a pattern match on the method name. Another would be to specifically look for this pattern since it is a common one.

Re: Option to Ignore certain classes

I'm using ncover to test a very large assembly that is full of generated code (like strongly typed datasets).

The //ea option is not really working for me. A pattern match for exclusion by class name would be extremely helpful.

On the same token, a pattern match for inclusion would also be very helpful to perform isolated ncover reports on only specific portions of a large assembly.

Re: C# 2.0 yield keyword causes InvalidProgramException

I'll look at it and let you know. I'm sure its just an opcode that I am interpreting incorrectly or something like that. Thanks for reporting it.

Re: C# 2.0 yield keyword causes InvalidProgramException

This was really causing me some grief in my coverage tests. So I investigated.

The problem is caused by

ILInstructionBranchSwitch :: OffsetBranch in ilmorph.h

it should read :

virtual void OffsetBranch(DWORD instrOffset) {

for (UINT32 i=0; i < TargetCount; i++)

{

Targets[i] = TargetInstructions[i]->NewOffset - NewOffset - GetILLength();

if (TargetInstructions[i]->IsSequencePoint)

Targets[i] -= instrOffset;

}

hope this helps.

Re: C# 2.0 yield keyword causes InvalidProgramException

Thanks for the investigation! That is a great help. I did spend some time on it myself, but did not find the exact problem. I'll try to get the fix out to you as soon as possible.

Re: C# 2.0 yield keyword causes InvalidProgramException

Wow, nice work g8zpd!

Cheers,
- Kim

Re: C# 2.0 yield keyword causes InvalidProgramException

Do you need another build right away, or can you wait a week or so for the next release to come out?

Re: C# 2.0 yield keyword causes InvalidProgramException

I'm fine with waiting, FWIW.

- Kim

Re: C# 2.0 yield keyword causes InvalidProgramException

Hello!

Could you please tell when the next build will be available as I have an error similar to the listed above (problem with unit tests run under NCover and C# generics) and need to know when it will be fixed.

Thank you for your help!

Avos

Re: C# 2.0 yield keyword causes InvalidProgramException

Sometime in the next few days. I'm working on some issues right now. Contact me privately and I can email you a new CoverLib.dll that has the problem fixed.

Re: C# 2.0 yield keyword causes InvalidProgramException

Thank you for the new version! It works greatly and all my problems with NCoverage are solved now!

Avos

Re: C# 2.0 yield keyword causes InvalidProgramException

I appreciate the timely response to this issue, if anyone is able to forward the fix please PM me.

Thanks

Re: C# 2.0 yield keyword causes InvalidProgramException

Fixed in 1.5.7, coming out in the next few days.

Re: C# 2.0 yield keyword causes InvalidProgramException

Just downloaded and installed 1.5.7 beta and I still get InvalidProgramException on a method using yield. I'll try to narrow the problem down to an example code later tonight.

Re: C# 2.0 yield keyword causes InvalidProgramException

Was too quick to reply. Just installed ncover, testdriven, nunit, redownloaded and reinstalled them all, and now it works without a hitch.

Re: Why is the coverage result file empty?

Try this command line instead:

NCover.Console //a ClassLibrary1 WindowsApplication1.exe

1. Parameters to NCover.Console are now prefaced with a double slash. All other parameters are passed through the profiled application.

2. The assembly name does not include the file extension.

Re: Why is the coverage result file empty?

Thank you very much!

I have solved this problem, The assembly name does not include the file extension.

Thank you again.

Re: Why is the coverage result file empty?

Should it only include the assembly name? So without a path and without it's extension?

Re: Why is the coverage result file empty?

Yes, the assembly name does not include the path or extension. It is the name that the CLR uses to reference the assembly. Note, that we do not need to locate the assembly, we just use the one with the unique name that is referenced by the tested program.

Re: Enhancement Request: Make Coverage Tree Percentages configur

Hi Mark,

Thanks very much for all the detail in your suggestion. Certainly allowing customisation of individual background colours shouldn't be much work and I can put that into the next release.

You do already have the ability on the "Coverage Options" tab for setting the "satisfactory coverage" percentage. Realistically is there any need to specify the others? You are basically saying that you want the ability to say that "full coverage" is less than 100%, and "no coverage" is greater than zero. Can you give me an example where this might be more useful than confusing to others?

If you want a threshold of say >95% to be considered "full coverage" visually, then you could just set your satisfactory coverage to 95% and set the same colours as for full coverage. What else might you want to do?

Re: Enhancement Request: Make Coverage Tree Percentages configur

You are basically saying that you want the ability to say that "full coverage" is less than 100%, and "no coverage" is greater than zero.

Actually, I'm saying that I want "partial coverage" to be greater than zero.

Realistically is there any need to specify the others?

Not if you set them the way I want. :-)
I just figure that different people will have different preferences for how it should all be configured. You seem to like 50% as the threshhold for partial coverage, I like 1%. To me, partial coverage means that some/any code was covered, but not enough to be satisfactory. Other people might want that threshhold to be 25% or 75% or some other arbitrary number. You never know what some manager is going to want on his/her reports.

What else might you want to do?

I can see where it might be useful to determine the category based on the number of lines of uncovered code instead of the percentage of covered code. Or in combination. For example, "Satisfactory coverage >= xx% or < xx lines of uncovered code."

I can see where it might be useful to save a default set of options as well as either a separate set of option settings for different projects (automatically read from a file in the current working directory on startup) or allow named sets of option settings.

I'd like the sort settings to be saved with the options.

I'd like to have the ability to run a batch file from within the program and have the xml file reloaded when the batch file completes. The batch file, of course, would run NCover with my preferred options. This would require either naming the batch files the same for each project (not a problem) or saving options separately for each project.

I have an NCover.cmd file in each test project folder (which is at the same level in the tree structure as the project I am testing), and they look like this:
if exist coverage.* del coverage.*
"C:\Program Files\NCover\NCover.Console.exe" "C:\Program Files\NUnit 2.2.8\bin\nunit-console.exe" ..\FooNUnitTests.vbproj //w "O:\Foo\FooNUnitTests\bin"

I'll let you know if I think of anything else.

Re: Enhancement Request: Make Coverage Tree Percentages configur

Hi Mark,

There seems to be some confusion over what constitutes partial coverage in NCoverExplorer. It isn't in fact 50% - that is just (in hindsight) a misleading example of a percentage on that options dialog. In actual fact partial coverage is anything greater than zero, but less than your satisfactory threshold. That is I believe what you were after?

I shall be more careful with my open ended questions in future like "what else might you want to do" or I will have a job for life... covering your points one by one:

I can see where it might be useful to determine the category based on the number of lines of uncovered code instead of the percentage of covered code...

You can do this already in the Coverage Options tab with the "Satisfactory Unvisited SeqPt" tolerance.

I can see where it might be useful to save a default set of options as well as either a separate set of option settings for different projects...

This is a good suggestion and has come from a few others as well. It's definitely on the list.

I'd like the sort settings to be saved with the options.

Will add to the list. I think there was a technical reason why I did not do that at the time but I can't remember why right now. Perhaps when I try to implement it again it will come to me... ;-)

I'd like to have the ability to run a batch file from within the program and have the xml file reloaded when the batch file completes...

An interesting idea I hadn't thought of. I had recently wondered about knocking up some sort of GUI for running NCover particularly when helping people out in the forums. Building that functionality directly into NCoverExplorer rather than "yet another executable" sounds a great idea. Nice one!

Good suggestions - I will start work on the next release this weekend which will certainly contain any low hanging fruit like background colours... keep 'em coming...

Re: Enhancement Request: Make Coverage Tree colors fully configu

kiwidude wrote:

There seems to be some confusion over what constitutes partial coverage in NCoverExplorer. It isn't in fact 50% - that is just (in hindsight) a misleading example of a percentage on that options dialog. In actual fact partial coverage is anything greater than zero, but less than your satisfactory threshold. That is I believe what you were after?

Quite right on all counts. The 50% is misleading and makes the true functionality (which is doing exactly what I want it to do) non-obvious.

kiwidude wrote:

I shall be more careful with my open ended questions in future like "what else might you want to do" or I will have a job for life...

Yes, I thought that was unwise of you, but thought I would take advantage of your lapse in judgement. :-)

However, you do not seem to learn from your mistakes, as you ended your reply with

kiwidude wrote:
keep 'em coming...

Thanks for your quick replies and for creating such an incredibly useful tool.

- Mark

Re: NCoverExplorer.Extras

Have been playing with creating some msbuild tasks. When you derive from "ToolTask", you have to provide the implementation for the abstract methods "GenerateFullPathToTool" and "ToolName".

The "GenerateFullPathToTool" is used to kick off the process using the System.Diagnostics.Process class. Here is an implementation of this if you wanted to provide the ability to just run the command from the users path, or use the provided ToolPath.

using System;
using Microsoft.Build.Utilities;
using Microsoft.Build.Shared;
using System.IO;

namespace ProjectX
{
   public class NotePad : ToolTask
   {
      protected override string GenerateFullPathToTool()
      {
         string tool = ToolName;
         if (!string.IsNullOrEmpty(ToolPath))
         {
            tool = Path.Combine(ToolPath, ToolName);
         }
         return tool;
      }

      protected override string ToolName
      {
         get { return "notepad.exe"; }
      }
   }
}

So, despite the name implying that you have to specify the full path to the tool, just specifying the toolname and setting the "ToolPath" to null (or empty string) will execute the command with just the executable name.

Thanks,
Mitch

Re: NCoverExplorer.Extras

Hi Mitch,

Thanks very much for posting your suggestions. I don't personally use MSBuild very much so that task hasn't had as good a thrash by me as the NAnt version. So your points on improvements are much appreciated.

If you like you can either e-mail me your version of the MSBuild task, or else I can just work through integrating what you have posted.

Re: NCoverExplorer.Extras

Mitch (and others interested)...

I have just pushed up a new zip file containing enhancements to both the NAnt and MSBuild tasks (build 2.0.1735):
http://www.kiwidude.com/dotnet/NCoverExplorer.Extras.zip

Specific changes to MSBuild task:
- Support for fallback of looking for NCoverExplorer in the current path, if a user does not explicity specify the ToolPath argument and they do not have TestDriven.Net installed
- Ensure that only a unique set of assembly names is ever passed to NCover.

Changes to NAnt task:
- Ensure that only a unique set of assembly names is ever passed to NCover.

Note on your other suggestion - there is no need to make your change concerning the project name. If you look in the source code you will see that it is passed to the config file which in turn is passed in the command line arguments to NCoverExplorer. It appears to work fine for me - were you experiencing a problem with this?

Please give this version a go and give me some feedback if possible (before I more publicly announce this on my blog).

Re: NCoverExplorer.Extras

A further update to these tasks is just now pushed up to my website in build 2.0.1736. As of NCover 1.5 the <Assemblies> nodes are written separately rather than as a semi-colon delimited list in the .ncoversettings file as they were in NCover 1.3.3.

Download from the same link as the above post.

Re: Welcome... (and useful links...)

Updated for the NCoverExplorer 1.3.5 release, which you can find more info on here:
http://www.kiwidude.com/blog/2006/10/ncoverexplorer-v135.html