How do code coverage tools work?

Question

How do code coverage tools such as NCover know which parts of the code were executed and which parts were not?

Answer 1

Here is a technical article on How to Implement Test Coverage Tools for Custom Languages .

My company is creating a family of testing tools for Java, C #, C ++, PHP, COBOL, PLSQL, ... based on this principle.

Answer 2

Quote directly from NCover Frequently asked questions : NCover reports the percentage of branches in the code that was taken during your automated testing. He achieves this by using the source code in each branch and writing the "hit" points to the file. These “hit” points are then compared to the common possible points, which could be “hits”.

Answer 3

I know this is an old question, but if you are still interested, you can see an example of how such tooling is performed for .NET applications, considering the OpenCover open source project.

OpenCover inserts breakpoints at significant points in the code.

• It uses sequence points taken from a PDB file to cover a line of code.
• To cover the branches, he types COND_BRANCH, picking the transition target and the next instruction after the transition command, that is, without a jump.
• For instrumentation tools, he sets the first instruction of any method.

All these rules apply in CoverageInstrumentation.cpp after the corresponding points have been located using Mono.Cecil and passed to the profiler from the console host.

The source code for PartCover is also available (as indicated), but it is much more complicated, but it also uses the sequence points from the PDB to determine where it encodes the code.

Answer 4

From this source:

NCover uses the .NET Framework profiling API to monitor application execution. When a method is loaded using the CLR, NCover retrieves the IL and replaces it with the IL code with tools

In short, he fixates on compiling on time.

Not all tools work the same way. Other tools work by changing the bytecode of your application after compiling the code.

Answer 5

This requires that you run your tests once with code coverage analysis turned on, and then simply count the number of blocks (i.e., area blocks) that were covered and compared with the total number of blocks in the tested projects (projects).

The main reason is that if every possible combination of code blocks is covered, all code paths are covered by ¹ . The main argument against being too heavy in code coverage numbers is that "light" blocks, such as getters and setters, which do not give real value (and are unlikely to make mistakes ...) count as many more error-prone blocks code.

---

^{1) As Ira Baxter noted in the commentary, the previous wording of this proposal was incorrect. Please read the comments to discuss this issue.}