Does anyone know how I can do either of the following?
- Calculate the total "number of blocks" in D so that I can manually adjust the coverage report to be correct?
- Get the Coverage report to automatically show the number of blocks not covered for assemblies that are instrumented for coverage but are not tested at all?
While I do want test coverage to improve I am analyzing coverage reports saved at historic points in time in the code base. Thus I don't want to create a test that simply executes at least 1 block of code in each assembly and the re-calculate test coverage by running the tests. That would be a pretty time consuming work-around to something that seems like a simple problem.
Posts
2 comments:
I don't this this is a bug, more of just a way you are looking at how you think it should work.
For now just remove the assembly from unit testing coverage until you have tests on it. Your historical stats will still work
80% of X # of code blocks
later add it in once you have a test on it
80.5% of X+assembly # of code blocks.
I think you're right, but my assertion is that my expectation is realistic and the outcome provided is not a good user experience.
Removing D doesn't get me to my end goal of being able to trend the total test coverage of my operational code base. To continue the example, let's say A, B, and C are combined 10,000 blocks of code and are 80% covered, and D is 5,000 blocks and 0% covered.
My first measurement without including D would show 80% test coverage in the build report.
Now, I am working on my project and I add a few tests for D and get it to 10% covered.
My second measurement including D will show (80% * 10,000) + (10% * 5,000) / (10,000 + 5,000) = 56.7% test coverage in the build report.
So my test coverage is reported as taking a dive, even though I actually added more test coverage. I then have to explain to my team why a positive contribution I made shows up negatively on the build report. Additionally any trending annalysis will always need to have an asteriks at this point in time because the set of code being reported on changed.
Ideally if I instrument an assembly for test coverage I would expect it to give me test coverage results.
JB
Post a Comment