Cobertura requires raw ratio values #42
Conversation
|
I'd not sure really how to test externally. I'd just setup some values that you know would fail under the old code and generate a report and assert the outcome. Also, under the changes you've made, won't you get things like 0.6666666666 |
|
Yes, agree that I could write a failing test for this specific case but I'm slightly concerned that there might be other issues. I hoped that a parser written externally might give more confidence. It seems as though the Cobertura team don't do anything more than check against the DTD though... Yes, agree that you get the full resolution of the ratio rather than a rounded version, but since this is the machine-readable aspect of the coverage (rather than the HTML version) I thought it was ok to report a full number. However, doing this does mean that the unit test will have to apply some sort of epsilon check. |
|
Other people have written plugins that rely on this output now. I'd be reluctant to allow it to output anything other than 2 decimal places just in case. I mean it's a trivial change right. We can just do another formatted output method. |
|
I think they're going to have to update their consumer regardless - the number will be scaled down by a factor of 100. Alternatively we could produce a new file for the gradle-scoverage plugin, but that seems odd to me. |
|
I'd happy to make the breaking change because we're correcting our format to match the proper cobertura output. I just think it should be truncated to 2dp. |
|
Cobertura don't seem to truncate their output, but I do see value in not pretending that a code coverage statistic is accurate to 9 decimal places. I'll update the patch request. |
Cobertura requires raw ratio values
I tried some of the major consuming plugins (jenkins, sonar) in an attempt to validate that the generated xml is parseable externally.
However, this brings in a lot of dependencies and/or new repositories.
Do you have any thoughts on a way to effectively test this change?
Thanks,
Stu