Icon for NCOVER
Icon for NCOVER
On the next version of NCOVER, why not add the very nice looking icon on the website to NCover.Console.exe?
Re: 1.5.2 exclusion feature
My log file appears to have a "match" line for every class I applied the attribute to, like below:
MESSAGE: Found Attribute [BusinessLayer.NCoverIgnoreAttribute], Excluding Item from Coverage
MESSAGE: Class Excluded
However, they still show up in the coverage report.
Hope this helps track it down.
Re: 1.5.2 exclusion feature
Same situation, but executed method with Skip attribute...
using System;
using NUnit.Framework;
[AttributeUsage(AttributeTargets.All)]
class SkipAttribute : Attribute {}
[TestFixture]
public class Class1
{
void Method1(){} // executed, 100% coverage, Ok
[Skip]void Method2(){} // not executed, 0% coverage
[Skip]void Method3(){} // executed, but 0% coverage
[Test]public void Test1()
{
Method1();
Method3();
}
}
command:
"c:\Program Files\NCover\NCover.Console.exe" "c:\Program Files\NUnit 2.2.6\bin\nunit-console.exe" ClassLibrary1.dll //a ClassLibrary1 //w "ClassLibrary1\bin\Debug" //ea SkipAttribute
Coverage.Log:
...
MESSAGE: Monitoring Assemblies: ClassLibrary1;
MESSAGE: Excluding Types and Methods with these Attributes: SkipAttribute;
...
Coverage.Xml:
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet href="coverage.xsl" type="text/xsl"?>
<!-- saved from url=(0022)http://www.ncover.org/ -->
<coverage>
<module name="c:\windows\temp\nunit20\shadowcopycache\632745970413593750\tests\assembly\dl2\fe141f69\ae08dc7e_da28c601\classlibrary1.dll" assembly="ClassLibrary1">
<method name="Method1" class="Class1">
<seqpnt visitcount="1" line="10" column="17" endline="10" endcolumn="18" document="d:\classlibrary1\classlibrary1\class1.cs" />
</method>
<method name="Method2" class="Class1">
<seqpnt visitcount="0" line="11" column="23" endline="11" endcolumn="24" document="d:\classlibrary1\classlibrary1\class1.cs" />
</method>
<method name="Method3" class="Class1">
<seqpnt visitcount="0" line="12" column="23" endline="12" endcolumn="24" document="d:\classlibrary1\classlibrary1\class1.cs" />
</method>
<method name="Test1" class="Class1">
<seqpnt visitcount="1" line="16" column="3" endline="16" endcolumn="13" document="d:\classlibrary1\classlibrary1\class1.cs" />
<seqpnt visitcount="1" line="17" column="3" endline="17" endcolumn="13" document="d:\classlibrary1\classlibrary1\class1.cs" />
<seqpnt visitcount="1" line="18" column="2" endline="18" endcolumn="3" document="d:\classlibrary1\classlibrary1\class1.cs" />
</method>
</module>
</coverage>
Hope this helps track it down.
Re: 1.5.2 exclusion feature
I found that if I specify the "simple" name for the method-level attribute (Test instead of NUnit.Framework.TestAttribute) that it does change the behavior, but not in the way that I had hoped.
The marked functions remain in the report, but are considered uncovered. My 65% coverage drops to 35% coverage, as every line of my unit tests is now considered uncovered, rather than being ignored completely.
Also, specifying a class-level attribute (TestFixture or NUnit.Framework.TestFixtureAttribute) seems to have no effect on the output.
Hopefully this is of use to someone in tracking down the bug. I'm very much looking forward to rolling out 1.5.x to our build system when this feature works.
Re: 1.5.2 exclusion feature
I'm having this same problem.
I've checked the following:
- The //ea is spelled correctly
- The class indeed has the attribute.
- The log file shows that the attribute class is being picked up. I see the following in the log
- MESSAGE: Excluding Types and Methods with these Attributes: my.CoverageExcludeAttribute;
By the way, great product!
Richard
Re: 1.5.2 exclusion feature
To all of you,
Great feedback. Looking into it now...
Re: 1.5.2 exclusion feature
i want the syntax for using the //ea attribute. i have tried a lot of ways but couldn't get through it.
Re: 1.5.2 exclusion feature
The syntax is just "//ea FullNamespaceClassName" - e.g. if you define an attribute "BarAttribute" in the "Foo" namespace, then it should be just:
ncover.console //ea Foo.BarAttribute ...
The easiest way we found of handling this was defining in our AssemblyInfo.cs (or in a CommonAssemblyInfo.cs which you link across projects) the following line:
internal sealed class CoverageExcludeAttribute : System.Attribute {}
That means anywhere in the .dll we can mark classes or methods with [CoverageExclude], do not have to add "using" statements throughout the code, and the command-line is simply:
ncover.console //ea CoverageExcludeAttribute ...
Even better, Jamie Cansdale has built in default support for an attribute named exactly this way into TestDriven.Net, so when you choose "Test with... Coverage" it will automatically apply a "//ea CoverageExcludeAttribute" argument, for when you view the results in NCoverExplorer.
One final point - there are some known problems with the coverage exclusion feature not always working correctly (as of 1.5.4) as mentioned in other threads. I believe these have been fixed by Peter to be included in the next NCover release.
Hope this helps,
Grant.
http://www.kiwidude.com/blog/
Re: 1.5.2 exclusion feature
has any had any luck with getting the //ea to work?
I've added it to mine with the full namespace of the class i'm wanting to exclude. According to the NCover log, it reconises that it need to be exlucluded, but nothing different happens.
Re: 1.5.2 exclusion feature
Well, as per the above post, yes it should work.
Just from your comment above - you do realise you have to define an attribute and put that on the class you want to exclude and put the namespace for that attribute name in the //ea arguments i.e. not the name of the class you are excluding itself?
i.e. define an attribute:
internal sealed class CoverageExcludeAttribute : System.Attribute {}
Apply it to your class or methods:
[CoverageExclude]
public class SomeClassIWantToHide
{
...
}
Then pass the name of that attribute in the //ea arguments...
ncover.console //ea CoverageExcludeAttribute ...
Re: 1.5.2 exclusion feature, multiple exclusion
Hi,
is it possible to exclude multiple attributes. When writing WPF apps, you get two candidates that you want to ignore for sure in addition to CoverageExcludeAttribute:
System.Diagnostics.DebuggerNonUserCodeAttribute
System.Runtime.CompilerServices.CompilerGeneratedAttribute
I have tried using //ea twice, but that does not work. Is there a magic delimiter like , or ; ? Does multiple exclusion work at all?
Friedrich Brunzema
Re: 1.5.2 exclusion feature, multiple exclusion
Hi,
I hate answring my own questions; should have tried it right away. The magical delimiter is the semicolon, and things seem to exclude OK in version 1.5.5
//ea System.Diagnostics.DebuggerNonUserCodeAttribute;System.Runtime.CompilerServices.CompilerGeneratedAttributeF.
Re: Can't get Coverage File output
Assemblies should be just the name, not the path (i.e. <Assemblies>Common</Assemblies>)
Re: Can't get Coverage File output
Hi Peter,
I tried your suggestion but it's still not working. I still only get the NCover log file but no coverage file (CommonTests.NCover.xml).
Any other ideas?
Cheers,
r/
Re: Can't get Coverage File output
peterwald wrote:
Assemblies should be just the name, not the path (i.e. <Assemblies>Common</Assemblies>)
Could you explain what the difference is between the assemblies passed in to the commandLineArgs, and those listed in assemblies. Which is equivalent to the //a parameter that gets passed in to ncover.console.exe?
For instance, in my old build file, I had this code:
<exec program="${ncover.exe}"
workingdir="${output.dir}">
<!-- This argument is for NCover, telling it which process to monitor for coverage -->
<arg value="${nunit.exe}" />
<!-- This argument is for NUnit, telling it which assembly to search for fixtures -->
<arg value="/xml:${output.dir}\nunit-results.xml ${build.dir}\mytest.dll /nologo" />
<!-- This argument is for NCover, so send it verbatim -->
<arg line="//a My.Namespace.To.Test" />
</exec>How would that translate into the new <ncover> task?
Re: Can't get Coverage File output
Ah, forget that, I think I've cracked it. My build file now looks like this:
<ncover program="${ncover.exe}"
commandLineExe="${nunit.exe}"
commandLineArgs="${build.dir}\mytest.dll /xml="${output.dir}\nunit-results.xml" /nologo"
workingDirectory="${output.dir}"
coverageFile="${output.dir}\coverage.xml"
logLevel="Verbose"
logFile="${output.dir}\coverage.log">
<assemblies>
<include name="${build.dir}\mytest.dll" />
</assemblies>
</ncover>And that now generates the coverage.xml file that I was hoping for. Of course, nothing is ever simple, and now <ncoverexplorer> won't process it, with a Not a valid report type error, but hey, life wouldn't be fun if weren't constantly being tested!Re: Can't get Coverage File output
There is not enough coffee in my life. Fixed the Not a valid report type error, by installing the latest version of NCoverExplorer. Well duh!
Re: Can't get Coverage File output
Hi mate,
Yes the "example" included in the zip with my <ncover> and <ncoverexplorer> NAnt tasks that you are now using started from has a report type of "4" from memory, which is the latest "Classes per namespace per module" report that I put into NCoverExplorer 1.3.4. Hence why the latest NCoverExplorer version upgrade fixed it for you. Alternatively you could have chosen one of the other report types - but obviously I would rather everyone upgrade to the latest NCoverExplorer anyways! Sorry for the confusion it caused you.
Glad to hear the <ncover> task got you up and running, hope it proves useful to you.
Regards,
Grant.
http://www.kiwidude.com/blog/
Re: NCoverExplorer.NAntTasks
Hi Montana,
Thanks for bringing this up. I did wonder recently if there could be a problem like that- particularly on CC.Net build servers where you are likely to have concurrent NCover executions. However I thought that registry lookup should only be needed once when the profiler first starts up so I figured the chances would be absolutely miniscule of the timing clash? I am amazed however you have hit it?
The approach I took for our build servers as a safeguard was to still use regsvr32 in the NAnt script (and not unregister it afterwards). That works fine provided all projects on the build server use the same NCover version. However we also only run coverage on that server on our daily builds and they are timed to not run concurrently so I am not really going to hit that scenario anyway.
I will have a think about what can be done for this. Peter added a //reg argument in 1.5.6 as an option but that does exactly the same thing of registering and unregistering. I cant rely on people only using that version (although once 1.5.7 comes out I highly recommend that every NCover user out there switches to it for all the things it will fix).
Certainly I wanted to make my entire registration optional (with the default registration true for backwards compatibility). However what you are wanting effectively is a registration without unregistering - I guess the question is whether that should be the default behaviour, or do I make this new attribute a tri-state enum. Reluctant to overly complicate it all and confuse people!
Alternatively there could be some more smarts in the addin which looks to see if it can find a registry entry for NCover, adds it only if it cannot find one at all (dangerous if you use multiple NCover versions on the same box) and maintains a running server-wide count of NCover executions. However that relies on all executions on the box running my NCover task - there might be legacy scripts running older versions or using the command line directly etc.
Not a trivial one - perhaps registering but not unregistering is the safest option. Thoughts anyone?
Re: NCoverExplorer.NAntTasks
Hi Grant,
Thanks for the quick reply.
You make some very good points.
First, I can't imagine using different versions of NCover. Maybe it's just how we do things where I work. So maybe you can make the assumption that only one version is being used - the latest.
Second, it's not the registration part that fails but rather the unregistration because it's throwing an ArgumentException if the Subkey is not found (MS code throws the exception if you try and delete a registry key that doesn't exist). I was easily able to reproduce this by creating an ad-hoc test case in the NAntTasks assembly and running it. Because the exception is going off it creates a downstream effect that causes other tests to fail (and it throws off coverage analysis results because the profiler was disconnected)
From my experience, the simplist approach is best. Since this option might be new for "new" versions of NCover, perhaps you just have a boolean - RegisterUnregisterCoverLib or something like that. The default could be True so you keep the register/unregister behavior like it is now but those who want to change that behavior can (like me). If it's set to false, turn off both the register and unregister behavior and make the client be responsible for registering CoverLib (like running a task for regsvr32).
And I already have a Task that executes regsvr32 on CoverLib.dll to make sure it's registered anyway. I do not unregister the DLL.
I was actually going to try and setup a server side binary file that kept track of the # of times CoverLib was registered and the # of times it was unregistered and only remove the key from the registry once the count gets to 0. But I found it was time consuming and I wasn't really familiar with the code setup. I abandoned the idea and just commented out the code in the unregister method. And since I only use 1.5.6 of NCover it wouldn't be a problem with other versions being used since I don't use earlier versions.
Kind Regards,
Montana
p.s. When do you expect NCover 1.5.7 to come out? I'm always up to try out the latest version (though I prefer not to use betas if I can help it on our CCNet servers)
Re: NCoverExplorer.NAntTasks
Montana,
I'm hoping to get back onto NCoverExplorer in a week or so, at which point I will add your suggestion of a new attribute to control whether it registers or not.
As for 1.5.7 - good question. Peter was working on it the last few weekends and I'm sure he wants to get it off the todo list!
I do know he has put a lot of work into a test suite for it to provide automated repeatable system testing and adding to it the various corner cases which have traditionally tripped NCover up. Between that and a few hours from myself chipping in on identifying issues and bug-fixes, plus some significant changes Peter made internally I'm optimistic this should be the most solid NCover version yet...
Like you I'm itching to try it out when Peter reckons it's ready - the last time I bugged the poor guy about it was a few weeks ago and he said "hopefully in a few weeks" so fingers crossed that means early Feb perhaps? You now know as much as me...
Re: NCoverExplorer.NAntTasks
Montana,
The latest version of the NCoverExplorer.Extras zip file (1.3.6.9) contains an update to the ncover NAnt/MSBuild tasks that implements a reference count for the registration. So the first execution will register coverlib.dll in HKCU, subsequent ones while that is running just increment the count in the registry. Similarly as ncover task executions finish the count is decremented until the last one which will unregister coverlib.dll.
This should prevent any issues with people relocating NCover or having it permanently installed in another folder on their machine which would be the case if I just registered without unregistering. I decided that adding attributes to the task to control it all was just unnecessary complication.
Re: NCoverExplorer.NAntTasks
Hi,
First of all NCoverExplorer rocks. The Nant task makes the build file much easier to read. Thanks a bunch.
Currently using NCoverExplorer nant task you could exclude an assembly or namespace or a class. But I'm runing ino much granular issue. I've a few helper methods in my class that I use TypeMock to mock it in my tests. Now NCover reports they are not covered. I used the NCover exclude attribute to get a better coverage report. The drawback is now I've to define and use this attribute in my assembly. If NCoverExplorer nant task allows to exclude methods as well, I do not need the attribute and my code looks clean plus I get better coverage.
Thanks
BuildGuy
Re: NCoverExplorer.NAntTasks
Hi BuildGuy,
Yep I understand exactly your issue and there are a few others who have requested this as well.
As I may have mentioned on other posts around this feature the reason I haven't put this in as yet is because I need to have a rethink about the NCE configuration xml format so I can support multiple "projects". Excluding assemblies using patterns like *.Tests is something you can reuse, but going to class and method level you now have a bunch of stuff that is very specific to a single project.
I don't really want to cause more pain for people by offering this feature now and then them having to refactor their configuration xml at a later date with dozens or hundreds of method exclusions. The exclusions would need a better/dedicated screen for viewing/specifying and there would be an impact on the reporting as well. So it's not quite a trivial change.
Not forgotten about - just needing to get a few other things demanding my time out of the way first... thanks for continuing to prompt me on this though...
Re: Merge creates duplicate method call entries
Are you using NCover 1.5.5? If you are then... don't! This is one of the many known issues with it. Generate the NCover files with NCover 1.5.4 and see if you still have the problem. Also, what version of NCoverExplorer are you using?
Re: Merge creates duplicate method call entries
OK
NCover 1.5.5.0
Explorer 1.3.5.1872
Which versions should I use?
Re: Merge creates duplicate method call entries
As I said above NCover 1.5.4 instead of 1.5.5. It is a "downgrade" in terms of known issues with generics coverage, but at least it doesn't suffer from the problem you experienced above.
As far as NCoverExplorer is concerned I released the official 1.3.5 build last week which is 1.3.5.1921 from memory.
Re: Merge creates duplicate method call entries
Hi,
I get the exact same problem. (included is a snipet in case it helps. It is taken from the generated merged file).
I have uninstalled 1.5.5 and installed 1.5.4 instead. I also get the 2 values for the 2 nunit runs (one is 100%, the other is 0%. I would expect the coverage to be considered as 100% (since one of the run covered the whole thing) but it does not seem to be the case. It gets a value somewhere in the middle.
I'm running everything from a nant script, calling ncover then ncoverexplorer with the tasks provided beside ncoverexplorer.
Here is the code.
<method name="WriteCommandLine" class="ImportExport.Program">
<seqpnt visitcount="12" line="172" column="13" endline="172" endcolumn="84" excluded="false" document="..." />
<seqpnt visitcount="12" line="190" column="9" endline="190" endcolumn="10" excluded="false" document="... />
</method>
<method name="WriteCommandLine" class="ImportExport.Program">
<seqpnt visitcount="0" line="171" column="9" endline="171" endcolumn="10" excluded="false" document="..." />
<seqpnt visitcount="0" line="172" column="13" endline="172" endcolumn="84" excluded="false" document="..." />
<seqpnt visitcount="0" line="190" column="9" endline="190" endcolumn="10" excluded="false" document="..." />
</method>
Any help welcome.
nick
Re: Merge creates duplicate method call entries
Hi guys,
Oops - the workaround I put in NCoverExplorer is in a version I hadn't gotten around to releasing yet.
I have just pushed this up now... you can download it from http://www.kiwidude.com/dotnet/NCoverExplorer.zip
Please give this a go and tell me how you get on. This is NCoverExplorer 1.3.6 which you can see the release notes for here:
http://www.kiwidude.com/dotnet/NCoverExplorerReleaseNotes.html
The main new feature is a find dialog to quickly navigate to a class (ctrl+F), plus a few bug fixes. There was some other stuff I was going to put in this release but that can wait for the next one. I will add a blog entry etc for it in a week or so - buried in day job stuff at the moment.
Please let me know if you find any issues with this release - this is the one that will be bundled with Jamie's next TD.Net version which will be coming out shortly.
Re: Merge creates duplicate method call entries
Should we use NCover 1.5.4 or 1.5.5 with this update of NCoverExplorer?
Thanks for the quick help. Always appreciated.
nick
Re: Merge creates duplicate method call entries
Hi,
The link you provided is to version 1.3.5.1921. The most recent file in the zip is from october 27, 2006.
Can you repost the link?
Thanks!
nick
Re: Merge creates duplicate method call entries
Hi Nick,
You want to try downloading from that link again? I just tried it and I get the set of files dated 27th Jan. If you are comparing to something you tried previously, I overwrote the zip at that location at the time I posted. Perhaps it has been cached somewhere?
As for which verison of NCover - my personal recommendation is to stick with 1.5.4 and then upgrade to 1.5.7 when it gets released. There are some fundamental issues with the changes Peter started introducing in 1.5.5 that he has addressed in the (hopefully upcoming soon) 1.5.7 which can greatly impact the integrity of the results being reported. Depending on what your code being tested does, how AppDomains are being loaded/unloaded etc you may or may not have experienced the problems. NCoverExplorer does it's best to work around some of those but if the data is invalid it is a case of garbage in garbage out.
Re: Merge creates duplicate method call entries
I'll have to remember this. Deleting the browsers cache enabled me to download it.
And it works perfectly fine. The coverage numbers are where I expected them to be.
Many thanks, and keep on the good work ; )
nick
Re: Merge creates duplicate method call entries
I went deeper into the results, and found 2 surprises.
First, the merging was done. Good. But it also made me realize that the coverage given was, well surprising. Of the 2 tests I am running, one is run in debug, the other in release. This would give me the output given above (3 lines in debug, and 2 in release. The test in release would test the function, but not the one in debug.)
The merging would then give:
<method name="WriteCommandLine" class="Program">
<seqpnt visitcount="0" line="171" column="9" endline="171" endcolumn="10" excluded="false" document="..." />
<seqpnt visitcount="12" line="172" column="13" endline="172" endcolumn="84" excluded="false" document="..." />
<seqpnt visitcount="12" line="190" column="9" endline="190" endcolumn="10" excluded="false" document="..." />
</method>
As you can see, the two lines in release are marked as being tested 12 times, while the "added" line in debug is marked as not tested. This is awkward since the line could not have been tested (i.e. does not exist) in release.
Is this part of the current problem of NCover you mentionned?
Also, there are 2 other functions in this class, one which has the exact same behavior and test coverage as this one. The other being a bigger function has similar behavior, but has a visited count of 0 for each line containing an opening bracket, again skewing the result. (I expect this to be the same problem since the line with the opening bracket does not seem to be there in release, and this is the flavor with wich it is being tested.
The other part is the merging of the results. I'm using the ModuleClassFunctionSummary report. For this class, it gives me a 100% coverage. Even if the first part was correct, I know this to be incorrect.
If I can help in any way by providing more info or some code example, feel free to drop me a line.
nick
Re: Merge creates duplicate method call entries
I might add that the module I mentionned being tested at 100% according to the report is marked as 48% by NCoverExplorer (When I open up the GUI on the merged result file).
When I use the non merged Release file, it is marked as 74%. This sounds about right (all tests for that class are done through the release build).
Thanks,
nick
Re: Merge creates duplicate method call entries
Nick,
I would probably need to see what the actual line of code is that corresponds to the sequence points to be definitive about this but almost certainly it is related to the sequence point issues with NCover 1.5.5 which I assume you used?
The exact issue is that Peter added some code to exclude from the coverage results certain noop instructions. Since a curly bracket is a noop, this gets excluded when the method gets tested.
The major bug is that if the method is NOT tested, then in NCover 1.5.5/1.5.6 the "optimisation" does not get executed, and so the sequence point information is passed through unfiltered into the coverage results.
When NCoverExplorer does the merge, it tries to identify methods using their method name, class, module and line number. Up to the most recent release you downloaded it was the start line number it used. However as you have seen the start line number can differ depending on whether a noop instruction existed there and if the method was tested or not. You can hence see why you would end up with "duplicate methods" in NCoverExplorer, as it thinks there is one starting on line 171 and another starting on 172.
In the latest NCoverExplorer you downloaded I changed the logic to work off end line number. It appears that there is never a noop at the end of the method so it is a more "reliable" way of merging to get rid of the duplicates. The downside is as you have seen it affects your coverage totals as you have sequence points which wouldnt appear if the method was called, but do appear when the code is not called - i.e. it is "impossible" to hit them!
So why did I bother, apart from to stop people freaking when they saw duplicate methods? Well, in an early build of NCover 1.5.7 I added a hack to merge sequence points internally in NCover and exclude the noops. This is the version of NCover that is shipped with TestDriven.NET currently.
The final version of NCover 1.5.7 will have the "proper" fix being applied to remove my temporary workaround.
Hope this helps explain things. In the meantime, use NCover 1.5.4, or at a pinch the version of 1.5.7 that ships with the latest TestDriven.Net. Note that the latter does still have other known issues which are addressed in the final NCover 1.5.7 but as I keep repeating it just depends on what your code is doing with AppDomains etc as to how badly you will be affected by those. I use NCover 1.5.4 myself at my "day job" if that's any help to guide you, until 1.5.7 hopefully gets released shortly.
Re: Merge creates duplicate method call entries
I've rerun and confirmed with the traces, this is 1.5.4.
I'll try to isolate an example with all the script to generate this and package in case this could help. Would you like me to send it by mail to you?
As for using the early build of ncover 1.5.7, unless there is a way to get it without TestDriven, I'll have to wait. (We dropped TestDriven when it became commercial).
Finaly, if you guys want any help to push these version, don't hesitate (I've looked but cannot find the source code).
Thanks,
nick
Re: Merge creates duplicate method call entries
If you can isolate it down into a small example then please do send to me by e-mail to support at ncoverexplorer.org. I will try it against the various NCover versions and see if there is a better one I can recommend as well as making sure it is indeed fixed with the latest. If I find one that works I will send it to you.
BTW you might want to reread that TD.Net license agreement. It wasn't Jamie's intent that everyone stop using the product - he wrote some blog entries about it you should read also. At $100 it's cheap as chips anyway for what it does and the great support he offers. (No I don't get any commission!).
As for helping out with NCover, thanks for the offer but it's basically all in Peter's hands as he seems to be keeping a tight rein on the latest versions of the code for the last few versions. He gave me some access to tweak a few things which makes life easier for me with all the NCover and NCoverExplorer support/dev work I do. For the most part though like everyone else it's pretty much a case of waiting for Peter to find the time to finish it off and release it.
Re: Merge creates duplicate method call entries
Hi,
I sent you the zip of the problem about a week ago.
I wanted to make sure you had everything. If you cannot reproduce, or require some other info, please don't hesitate.
nick
Re: Merge creates duplicate method call entries
Hi Nick,
My apologies - I should have replied to your e-mail. Sorry mate but I have had no chance to work on anything NCoverExplorer related. What you sent through sounded very thorough which was much appreciated. I wanted to both replicate the issue and try it with the various NCover versions to give you a glimpse of hope.
Perhaps this weekend I can grab a few minutes - I'm literally still working 7 days a week in my "paid" employment at the moment but think (hope) the end is nearing of that...
Re: Merge creates duplicate method call entries
No problem for the delay. There no rush for this and chances are I'll fall into a rush period shortly also.
Regards,
nick
Re: Merge creates duplicate method call entries
Apologies to Nick and anyone waiting in suspense for the answers. I have replied to Nick by e-mail as well.
The issue of the sequence points merging is a long standing bug in NCoverExplorer merging code. The issue is that NCover will only remove noop sequence points if the method is actually executed. When you merge two coverage files, it is likely that you will have methods with differing numbers of sequence points if they were called in one coverage run but not the other. If you just merge the visit count/sequence points together, you end up with the noop sequence points appearing in NCoverExplorer because the method at one point wasnt called - but when you did call it then the noop "doesnt exist" so NCover didnt say it was visited (Catch 22).
The latest build of NCoverExplorer now correctly handles this situation - while not yet the final build for the next release you can download it from http://www.kiwidude.com/dotnet/NCoverExplorer.zip
The second issue Nick raised was that of getting 100% coverage in his ModuleClassFunctionSummary coverage report. This was due to a misunderstanding on exactly what that report is intended to show. It is primarily a function coverage report, indicating the % of functions that were actually invoked, regardless of how much of each function's code was invoked. Some people like to use this over traditional coverage as it allows you to not have to worry about hitting exception handling code for instance. So in his case because all the methods in the dll were indeed called the function coverage % is 100%, regardless of how much of each method was actually executed due to if-statement conditions.
If you want to see a coverage report indicating that the sequence points within that method were not called, then you should use the ModuleClassSummary report which gives a coverage% based on the sequence points of code not hit.
Re: Merge creates duplicate method call entries
A reply for anyone else reading the thread. Nick sent me through several superb repro cases/scripts and thanks to those I've been able to make a number of fixes to NCoverExplorer to improve the handling of merging of coverage files.
What I had not realised before now is that the noop problems were not limited to NCover 1.5.5. NCover 1.5.4 only removes noops for the executed code within a method, not all the lines of code in the executed method (which the latest 1.5.7 does). So this means merging NCover coverage files is a lot more complex for the earlier NCover versions than I had catered for. Hopefully I've finally now got this nailed for all NCover versions.
For anyone wanting the fixed NCoverExplorer, download from the link below (build 1.3.6.7 at the time of writing this). I will do an official release probably this weekend.
http://www.kiwidude.com/dotnet/DownloadPage.html
Re: Coverage is shown 0% for tested dll
Amit,
You have double posted this in two forums. Rather than repeating myself everywhere please make any updates to the original thread:
http://ncover.org/SITE/forums/thread/918.aspx