• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

How does code coverage tools work?

 
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

I am looking for some article which explains how a code coverage tool works. Popular tools like emma and cobertura use byte code instrumentation. Byte code manipulation happens in original class file itself ? or it makes a copy and does manipulation there?

These tools provide code coverage for every line. So do these really add lot of code to find if it each line is traversed?

The doubt i have is , what will the instrumented file look like? Instrumentation code at each line ?

Thanks
Praveen
 
author
Posts: 23959
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

The doubt i have is , what will the instrumented file look like? Instrumentation code at each line ?



Bytecode instrumentation generally involves adding extra code that increment counters -- and these counters are used to indicate whether something happened (was reached). For example, if a block of code never gets executed, then the counter for that block should still be zero.

Generally, it is not needed to instrument every line. You just need to instrument branches. For example, inside and outside of an "if" condition, inside and outside of an "while" condition, before and after a block that contains a return statement, etc.

As for the file, there is probably no need to instrument the classfile (but this can vary from tool to tool)... it is possible to instrument the byte codes when it is loaded into the VM, via a classloader.

Henry
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are several variations, but the classic approach is to create a new .class file which contains extra code after each original source line that just records that the line has been executed. That code could be the equivalent of something like

LoggingClass.increment("MySourceFile.java", lineNumber);

Generally the instrumented code is stored in new class files, so they're created as an extra build step.

It's also possible to do code coverage at the JVM level, using the same APIs that are used to implement breakpoints in a debugger. This is generally less efficient, though.
 
Praveen Seluka
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Henry and Ernest.

From your comments, I understood that

1. Generally instrumentation happens on copy of original source.
2. they use counters to get the info if its traversed

From online resources, I found they would use CGLIB to do bytecode instrumentation. Normally, after a testsuite ran we can see the code coverage. So this means, the testsuite ran against instrumented classes and not the actual one.

I know that there are some security issues and some stuff related to digital signature. Dont they play any role.
 
Praveen Seluka
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ernest

It's also possible to do code coverage at the JVM level, using the same APIs that are used to implement breakpoints in a debugger. This is generally less efficient, though.



It will be great if you can point me to some resources to know about this.
reply
    Bookmark Topic Watch Topic
  • New Topic