How to Write Your Own Java/Scala Debugger
takipiblog.com
takipiblog.com
Today all (I think) code coverage tools use code instrumentation, potentially changing test results (as we run a modified version of the code we test). The impact of this is that most coverage tools suggest running tests twice - once without coverage tracking (the actual tests) and again with coverage, a practice that slows down builds.
Using the debugger interface for tracking code coverage means we are running unchanged code in tests, those not requiring a second run of tests just for coverage.
In addition, using the debugger interface, we can look at variable values and estimate coverage based on different states of variables in a statement.
I've been using it for the last year or two and love it! One of my favorite features is how easy it is to generate separate coverage information for unit tests vs. integration tests. Sonar provides excellent support for it, as well.
Both use instrumentation at loading time, which is great (because it is transparent). However, both recommend to run tests twice because of the instrumentation. In both cases, the Maven plugin runs tests twice - once for testing, and once for coverage - which is a total waist of time.
I was thinking on using the debug interface to track coverage without instrumentation, those without the risk of modifying the tests.