How to Write Your Own Java/Scala Debugger(takipiblog.com)
takipiblog.com
How to Write Your Own Java/Scala Debugger
http://www.takipiblog.com/2013/09/24/how-to-write-your-own-java-scala-debugger/
5 comments
Have you come across JaCoCo [1]? It does its instrumentation via a JVM agent at runtime-- no need to recompile your code just to test for coverage.
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.
[1] http://www.eclemma.org/jacoco/trunk/doc/
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.
[1] http://www.eclemma.org/jacoco/trunk/doc/
It is a great tool, and I have used it. I have also used Emma.
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.
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.
Am I missing something or does this post have a really poor title? The article is a very brief and high-level overview of some of the main topic headings related to writing debuggers. You are barely any closer to writing your own debugger after reading this article.
Yes, I thought that this would have more info that would be useful to get going.
Does anyone know of some open source java debugger code that I could hook up with a ncurses front-end ? that would be useful when I'm debugging customer issues.
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.