NCover.org and NCover at SourceForge

Just found the NCover.org web and the NCover tools and think it's great. I had previously looked at the NCover homepage at SourceForge but since my project is in VB.Net and the SourceForge project cover only C#, I couldn't use it.

Was really happy to find this site and tool instead since it helps me out a great deal. But, what's the connection between ncover.org and the SourceForge project?

Regards,

Magnus

Re: Link Files in Visual Studio

Do you care what your coverage is in the unit test project (personally we dont and always exclude unit tests from the coverage results). If that is the case you can either setup a coverage exclusion using NCoverExplorer to exclude your tests assembly, or use the NCover //a argument (or equivalent NAnt/MSBuild argument) to just profile coverage of your "Product" assembly.

Re: Link Files in Visual Studio

You're right, I dont really care about the coverage of my unit test project.

However, because of the link files in our unit test project, we actually (implicitly) duplicate the product namespace and classes in the unit test assembly. We can't really blame NCover for this. It's a poor design from our side.

NCover(Explorer) then reports the coverage for the duplicated project code inside the unit test assembly, not for the original product code. When we then exclude the unit test assembly from coverage, the product code coverage seems way too low.

(The "Namespace % Summary" report even reports the original and duplicated namespaces as separate with different coverages.)

I guess the best solution would simply be to get rid of those silly link files from our unit test projects.

Regards,

Mads

Re: Link Files in Visual Studio

I am intrigued when you say that simply excluding the assembly from coverage does not work. Does that mean when the tests run that the code being executed is actually in the linked file within the test assembly, rather than in your "Product" assembly? Hence why your coverage appears lower than it should? I can't think of another reason off the top of my head as to why just excluding the test assembly shouldnt give you your desired result. What sort of code is in that linked file?

If that is what you mean then you could argue that actually the "coverage seeming too low" is not actually the case and the fact that you are not exercising that code in the target "Product" assembly is rightly being shown as lower coverage. The fact that the file is "linked" and hence you "know" it should be marked as coverd is just an incidental file system feature - for instance if someone were to copy instead of link the file accidentally in your test assembly (very easy to do) then they could change independently and it would then be very much right to report the code was not exercised...

It's all just a midly interesting theoretical debate anyways (assuming I am not talking complete twaddle) seeing as you appear to have concluded that it perhaps isn't the right thing to be doing and will refactor them...