VSTS Code Coverage bug?

Question

Has anyone experienced this VSTS Code Coverage "bug?" Do you have any suggestions?

I am doing code coverage analysis with Visual Studio, which is generally an easy task now with the tools that are included. However, I have an issue that I can't overcome. Let's say I have assemblies A, B, C, and D and have marked them all for coverage analysis. I run the tests and look at the results and find a report that contains A, B, and C - but not D. I investigate and find that no tests actually execute any code in D (let's say it's the asp.net front end and I don't leverage UI testing yet). Because there are no tests for D causing D to be missing from the report the total code coverage percentage and "blocks not covered" are incorrect.

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.

Answer 1

I ran into this once, it is very annoying. In my case, there were a number of dlls not covered, so I ended up estimating blocks/kb for our code base by using the covered dlls information divided by their size. Then of course to get the number of blocks for the uncovered dlls, you simply multiply your average by the size of the dll. This is not the most accurate method but it gets you a quick ballpark, and you can determine your error by calculating your known dlls and comparing against the actual values. It is helpful if you have a good number of assemblies that are calculated.

Of course, you could just do a LOC count (ignoring comments) and figure on a single LOC roughly equivalent to a block. If I remember correctly that fairly accurate, and so should get you even closer.

The only way I know of to force a report on uncovered assemblies is to actually write a test that loads the assembly (the test doesn't even need to do anything).