How do code coverage tools like NCover know what parts of the code were executed and what parts were not?
标签:
code-coverage
相关问题
- Xcode Code Coverage and fopen$UNIX2003
- Is there any means by which I could evaluate the t
- Partial Code Coverage C# - Nunit
- Coverage fatal error (EclEmma)
- How do I get code coverage of Perl CGI script when
相关文章
- Skipping JaCoCo execution due to missing execution
- Is there still no solution for ignoring setter/get
- Visual studio code coverage from many different un
- Jacoco code coverage show 0% coverage on Jenkins
- Can't analyze code coverage with Visual Studio
- Emma does not generate coverage.ec
- How do I generate coverage xml report for a single
- Find unexecuted lines of c++ code
Here's a technical paper on How to Implement test coverage tools for arbitrary languages.
My company builds a family of test coverage tools for Java, C#, C++, PHP, COBOL, PLSQL, ... based on this principle.
From this source:
So in short, it hooks itself into the just-in-time compilation.
Not all tools work the same way though. Other tools work by modifying the bytecode of your application after the code has been compiled.
It requires that you run your tests once with code coverage analysis enables, and then simply counts the number of blocks (that is, scope blocks) covered and compares to the total number of blocks in the project(s) you are testing.
The basic reasoning is that if each possible combination of code blocks is covered, all code paths are covered1. The main argument against putting too much weight in code coverage numbers is that "easy" blocks like getters and setters, that give no real value (and could hardly go wrong...) count just as much as more error-prone blocks of code.
1) As noted by Ira Baxter in a comment, the previous wording of this sentence was incorrect. Please read the comments for some discussion on this.
I know this is question is old but if you are still interested you can see an example of how such instrumentation is performed for .NET applications by looking at the open source project OpenCover.
OpenCover inserts instrumentation points at significant points in the code.
All of these rules are applied in CoverageInstrumentation.cpp after the appropriate points have been located using Mono.Cecil and passed to the profiler from the console host.
The source code to PartCover is also available (as indicated) but this is much harder to follow but it also uses sequence points from PDBs to determine where it instruments the code.
Quote straight from the NCover FAQ: NCover reports the percentage of branches in the code that have been taken throughout the course of your automated testing. It achieves this by instrumenting the source code at each branch, and writing the 'hit' points to a file. These 'hit' points are then compared to the total possible points that could have been 'hit'.