How to know branch coverage

Hi I just tested NCover. It is amzing!!!.

I've a question. Is NCover reporting the branch coverage.

If so, how to do that?

Thanks Again!

Re: How to know branch coverage

Currently, NCover reports only statement coverage. I have plans to add branch coverage soon.

Re: NUnit crashes when NCover is ran with the verbose output swi

Are you saying that it works with verbose? Or it doesn't work with verbose?

Re: Running NCover from MSBuild - Error MSB3073

peterwald said:

"NCover.Console.exe //x NFPCoverage.xml "C:\Program Files\NUnit-Net-2.0 2.2.6\bin\nunit-console" \"C:\Source Code\NFP\NFP.Domain.Services.Tests\bin\Debug\NFP.Domain.Services.Tests.dll""

What about the highlighted character there. That doesn't look right.

Thanks for the quick response!
I use the backslash to escape the space in C:\Source Code... If I remove it I get the following error:
"Assembly not found: C:\Source" and after that "The command "NCover.Console.exe //x "C:\Source Code\NFP\NFPCoverage.xml" "C:\Program Files\NUnit-Net-2.0 2.2.6\bin\nunit-console" "C:\Source Code\NFP\NFP.Domain.Services.Tests\bin\Debug\NFP.Domain.Services.Tests.dll"" exited with code 2."

So with the backslash - when I opened the buildlog, I got the following error: Profiled process terminated. Profiler connection not established. I reregistered CoverLib.dll as they suggested in this post and ran it again.
That removed that error, and in the buildlog I can see that the tests are run through NUnit, gives me the feedback: Tests run: 78, Failures: 4, Not run: 6, Time: 57.596 seconds, lists the failures and tests not run. (Exactly as when it is run from command line, which sucessfully writes the coverage file).
But then directly after that is this line, which is also displayed on the CruiseControl dashboard:
<error code="MSB3073" file="C:\Source Code\NFP\Build\nfp.msbuild" line="20" column="3">
<![CDATA[ The command "NCover.Console.exe //x "C:\Source Code\NFP\NFPCoverage.xml" "C:\Program Files\NUnit-Net-2.0 2.2.6\bin\nunit-console" \"C:\Source Code\NFP\NFP.Domain.Services.Tests\bin\Debug\NFP.Domain.Services.Tests.dll"" exited with code 1.]]>
</error>

Any clue?
Thanks,
Thea

Re: Running NCover from MSBuild - Error MSB3073

Update: It does create the NFPCoverage.xml file perfectly. But it causes the build to fail and throws this error on the build report in CruiseControl:

error MSB3073: The command "NCover.Console.exe //x "C:\Source Code\NFP\Build\NFPCoverage.xml" "C:\Program Files\NUnit-Net-2.0 2.2.6\bin\nunit-console" \"C:\Source Code\NFP\NFP.Domain.Services.Tests\bin\Debug\NFP.Domain.Services.Tests.dll"" exited with code 1.

Thanks,
Thea

Re: Running NCover from MSBuild - Error MSB3073

I think this is normal behaviour. You said that nunit encountered failures - it then returns an error code which ncover passes on. Surely you want the build to stop if you have test failures.

Dave.

Re: Running NCover from MSBuild - Error MSB3073

Thanks for the reply. After more investigation: The tests run 100% when I run it directly from NUunit:
nunit-console "C:\Source Code\NFP\NFP.Domain.Services.Tests\bin\Debug\NFP.Domain.Services.Tests.dll"

But when I run it with NCover:
ncover.console "C:\Program Files\NUnit-Net-2.0 2.2.6\bin\nunit-console" \"C:\Source Code\NFP\NFP.Domain.Services.Tests\bin\Debug\NFP.Domain.Services.Tests.dll"

4 out of the 78 tests fails with the following error:
System.InvalidProgramException : Common Language Runtime detected an invalid program.

So I thought maybe it could have something to do with the NCover version, so I uninstalled it and installed 1.5.1 beta 2 again, but got the same error.

Still investigating,
Thea.

Re: Running NCover from MSBuild - Error MSB3073

Do you have an enumerator using a yield statement in that code? I have a bug related to the yield statement that I have not had a chance to fix.

Re: Running NCover from MSBuild - Error MSB3073

Hi Peter,

I realised that all the failed tests originate from one class which uses NHibernate and Iesi.Collections. Investigating it further.

Thanks,
Thea

Re: Exclusions stored in an external file

Hi Thomas,

I hadn't forgotten - they are on the list.

I've been diverted by building/ setting up a new PC (wickedly fast!), day job load (which pays the bills since of course NCoverExplorer pays nothing), various other little projects like "CCStatistics" for CruiseControl.Net - even knocked up a bit of code for Jamie for TestDriven.Net earlier this week to help him out for his RTM release shortly.

Not to mention all the time I spend trying to help people out here on the forums in Peter's "absence" and of course adding other features to the NCoverExplorer 1.3.5 beta... I've also got another new tool I was working on that's about 60% complete that I need to finish, and another couple in mind when I find the time...

Putting the tiny violins away now... to specifically address your "desired features". The short answer is they will not make it into NCoverExplorer 1.3.5 - which I locked down about a month ago and just haven't gotten around to publicly announcing on my blog. I'm waiting for TD.Net 2.0 RTM so people can get the combined releases, although the download links on my site are actually the 1.3.5 release version already.

Storing exclusion filters I feel would best be done by actually having a project file concept for NCoverExplorer. It's been requested by a few people and working on several projects myself here at work I know it can be a bit annoying to keep juggling settings. It's not an issue for the build server of course but is for the interactive GUI.

Project files opens up other questions. For instance should they be named/linked to the solution file - so that way Test with Coverage from TD.Net means it can pass the relevant project name when it launches NCoverExplorer to apply the right settings.

Filtering methods/properties - I know I replied back to your e-mail on this one with some questions about how that should work. At the moment a coverage exclusion like "*.MyClass" at "Class" level you can "get away with" as it is "unlikely" you will have name collisions. However lets say you have a "Name" property on "MyClass". Are you happy that you would specify "*.MyClass.Name" as the exclusion? You could of course fully quality it as "name.spaces.MyClass.name". Or if you really feel confident go for "*.Name"...

Obviously there's a fair bit of manual intervention going on to apply this across classes in your project, but I appreciate it is preferable for some people rather than using [CoverageExclude] attributes. Because of the management of all these exclusions you would definitely want to have the project file concept or else you would spend forever switching between them.

I will do my best to put it into the next release and of course you can "beta test" it for me even if it does take a while to be ready for the masses. I just need to decide where my priorities lie at the moment as to how quickly that happens. Do I start another release cycle of NCoverExplorer or try to finish some of the other tools which are work in progress that I desire to be using (and sharing with others who may want them as well)...

'Tis a tough life... ;-)

Re: Exclusions stored in an external file

Hi Grant,

the more flexibility the better it is ;-)) At the beginning a full qualified name "name.spaces.MyClass.MyMethod" for methods and properties would be fine. At a later time a smart filter, e.g. "*.MyClass.MyMethod" would simplify the work.

I agree with you that one would need some kind of a project file therefore. It seems that you already have this projectfile ConsoleExample.config.

Next week a student would join me to extend our tools chain. The exclusion topic is currently one priority one issue. He shall write some skripts to avoid the weaknesses of NCover.

If you like I would share the results of this work with you. If you're willing to share the current code, we might prototype the feature directly into NCoverExplorer.

Of course I will do beta testing again if you have a new version ready.

Ciao
Thomas

PS: Which kind of tool is in your pipeline? I'm looking forward to take a look to it...

Re: Bad performance on expanding nodes in big coverage files

Do you have .Net 2.0 on your machine by chance? If so, can you edit the NCoverExplorer.exe.config file and comment out the <supportedRuntime> element for .Net 2?

I noticed this the other day - I know Microsoft played around with the TreeView control in between .Net versions, and optimisations we made to get it running sweetly in .Net 1.1 seem to cause grief in .Net 2.0.

When I get some time I will profile it to figure out wtf Microsoft have busted so badly and the painful process of "retuning it". It's not something I'm looking forward to so if anyone has experience of some suggestions I am all ears.

The main optimisation from memory in .Net 1.1 is to do with the .Text property - setting this at the last possible moment when needing to change it. This is all done on demand as the tree is expanded - and seems to cause untold grief in .Net 2.0.

I may just remove the <requiredRuntime> for .Net 2.0 for now so "everyone" gets the benefit of the improved speed until I figure out a long term fix.

Let me know if that resolves the issue or it's something else gone wrong... we regularly load files in that order of size here at work without an issue (under .Net 1.1).

Re: Bad performance on expanding nodes in big coverage files

An update on this - I have confirmed the problem is indeed the .Net 2.0 TreeView control.

Here is a blog entry on the problem, a small sample app and the performance results:
http://www.kiwidude.com/blog/2006/09/net-20-treeview-performance-problem.html

In the latest build of the NCoverExplorer beta (1.3.5.1834) I have made two changes:

change the NCoverExplorer.exe.config file so that even if you have .Net 2.0 on your machine NCoverExplorer tries to run under .Net 1.1 first.
wrap the updating of the nodes when you expand in .BeginUpdate/.EndUpdate for people with only .Net 2.0 who force it to run this way.

This improves the performance significantly - but still nowhere near as fast as .Net 1.1. If anyone has some suggestions for giving it a boost I'm all ears.

Re: MSBuild and NCoverExplorer Help

Sorry, that error should read:

<error code="MSB4036" file="c:\projects\CITest\CITest.MsBuild.Build" line="28" column="5" timeStamp="10/25/2006 16:44:27"><![CDATA[The "NCoverExplorer" task was not found. Check the following: 1.) The name of the task in the project file is the same as the name of the task class. 2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface. 3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727" directory.]]></error>

Re: MSBuild and NCoverExplorer Help

Yes you should. You can either put it in the MSBuild directory, or you can explicitly reference it from a location of your choice. So you should have a section like this at the top of your script:

See the example.proj that comes with the NCoverExplorer.Extras.zip file and the included documentation.

Re: MSBuild and NCoverExplorer Help

Hi,

I am having exactly the same problem, and have hit a brick wall with how to fix it.

my UsingTask statement is:

The dll definately exists in this location (I copy and pasted the path).

Each time Cruise control runs the MSBuild script, it fails with the <error code="MSB4036" ......... error.

Is there anything else I need to do to get this to work? I have installed NCover. I hoped that installing NCoverExplorer would help, but no luck. I am not sure if there are any other dll's I need?

Any help greatly appreciated!

Re: MSBuild and NCoverExplorer Help

Hi Craig,

I take it the _ in the path above is just a typo in your post and not in the msbuild script?

What version of the NCoverExplorer.MSBuildTasks.dll do you have? The namespace did change to the syntax you show above in a relatively recent release. The latest release is 1.3.5.1921 (there is also 1.3.5.1949 which is a later version of the assembly but no change to the <NCoverExplorer> task, just a new <NUnitProject> task added).

Does the script run from the command line - i.e. is it only CC.Net executing it that is a problem?

Re: MSBuild and NCoverExplorer Help

One more thing - what are you actually trying to do? Run NCover? or NCoverExplorer? Or both? Have you added the alternate using statement if it is in fact the <NCover> task you want to execute?

See the NCoverExplorer.Extras.zip file in the Examples folder for example.proj which has all the syntax - here is a full example:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">;

<UsingTask TaskName="NCoverExplorer.MSBuildTasks.NCoverExplorer"
             AssemblyFile="NCoverExplorer.MSBuildTasks.dll"/>
<UsingTask TaskName="NCoverExplorer.MSBuildTasks.NCover"
             AssemblyFile="NCoverExplorer.MSBuildTasks.dll"/>


<Target Name="NCoverSimple">
    <NCover
        CommandLineExe="nunit-console.exe"
        CommandLineArgs="$(MSBuildProjectDirectory)\myapp.tests.dll" />
</Target>


<Target Name="NCoverExplorerReport">
    <NCoverExplorer
        ProjectName="TestProject"
        ReportType="ModuleClassSummary"
        OutputDir="$(MSBuildProjectDirectory)"
        XmlReportName="CoverageSummary.xml"
        CoverageFiles="coverage.xml" />
    </Target>

</Project>

Re: MSBuild and NCoverExplorer Help

Many thanks,

The problem was that my total ignorance of how MSBuild works meant my MSBuild file had tags all in the wrong place (I had a build target with the UsingTask element and NCover target element inside it).

Your example above helped enormously!

I now have Cruise Control building the solution and running NUnit, NCover & FxCop succesfully, and reporting the results on the cruise control dashboard - Perfect!

Cheers!