Merging output files with filter - Bug?
Hi,
at the moment i'm evaluating the dotCover 1.1 release. I have a scenario similar to the one decribed here: http://blogs.jetbrains.com/dotnet/2010/08/advanced-scenarios-with-dotcover-console-runner/
Merging two output files does not work properly if the output files were generated with filters.
I have two unit tests whose coverage results i want to merge. The config xml files for the coverage of each test assembly conain filters to just cover the assemblies which the unit test is intended to. So the result of the filters are disjunct.
When i'm merging the output files and create a report, only one of the two assemblies will appear in the report. The one that is the last in the merge list - if i change the order i get a different result.
If i don't specify any filter in the config xml files for the coverage of the unit tests it seems that the merging works correct. So do i use it wrong or is there a bug?
Thanks,
Carsten
Please sign in to leave a comment.
I am having the same issue with dotCover version 1.1.252.2
There seems to be a major bug in the Merge command. - The result of the Cover, Merge and Report operations always reports coverage data from only one of the covered test assemblies. This is true of the standalone product and the dotCover product bundled with TeamCity.
When I run the Analyse command on two different test assemblies, I get valid coverage data with different totals.
When I run the Cover command on the same two test assemblies. Then run the Merge command on the two coverage snapshots and the Report command on the merge results file. The report always contains information about only one of the covered assemblies.
I have not been able to get the Merge command to work correctly no matter what I try. By messing with the include filters in the cover config files I was able to get both assemblies to show up in the report, but the data was then reported incorrectly - the coverage totals were all zero for one of the assemblies, which made the coverage percent calculattion incorrect.
IMHO, this is a major bug.
Carsten, Leo,
Thank you for the feedback.
This is a known issue of the merge command.
Currently coverage filters are expected to be the same in all snapshots being merged.
This behaviour will be improved in one of the next releases.
I'm sorry for the inconvenience.
Ruslan,
are there any news on that topic? Meanwhile there wasn't any new release?
Thank you :-)
Carsten
Carsten,
Thank you for the interest to this topic.
This task was scheduled for the dotCover 2.0 which will be the next major release.
The next minor release is dotCover 1.2, it is expected to be published next month.
Meanwhile you can try the latest nightly builds from
http://confluence.jetbrains.net/display/DCVR/dotCover+1.2+Nightly+Builds
You can follow http://youtrack.jetbrains.net/issue/TW-17931. This is the TeamCity issue, not the actual dotCover one.
Hi,
i was happy when i noticed that there's a dotCover 2.0 EAP version.
But unfortunately the filter bug is still there. I thought it should be fixed in 2.0?
Thanks,
Carsten
Hi Carsten,
This task was re-scheduled for the one of the next releases which main goal will be console runner improvements.
Sorry for the inconvenience.
Regards.
That are really bad news - as we had decided for dotCover because fixing that bug was announced for version 2.0 whose release date is within our 1 year of free updates time.
I don't think that the next version will be finished until September?
:-(
Thanks,
Carsten
It is very unfortunate that this bug is still present in version 2.2. I am came across this issue when trying to integrate dorCover with CC.net.
The only workaround I found is to specify the same filters for all tests, which is wrong. It is said to see this issue not fixed almost two years after being reported.
MK
Hi Marat,
This issue is fixed in the upcoming dotCover 2.5 and you are welcome to try the latest EAP build: http://confluence.jetbrains.com/display/DCVR/dotCover+Early+Access+Program
Please let me know, if it doesn't help.
Regards.
Thanks for the reply. We'll be waiting for the realease.
MK