What is Code Coverage and Why Code Coverage?


What is Code Coverage
Code Coverage is an important measurement in Software Quality Engineering. While Software testing ensures correctness of the applications, a metric is required to track the What is Code Coverage Code Coverage is an important measurement in Software Quality Engineering. While Software testing ensures correctness of the applications, a metric is required to track the completeness and effectiveness of the testing undertaken. Code Coverage helps achieve reliable quality through identifying untested areas of the application.

Why Code Coverage
Software testing is a challenging function. The testers need to ensure complete functional and non-functional correctness of the product. Considering the complex workflows and use cases of modern day applications, the number of unique cases that the software can be used often run into millions, which is not feasible to be covered under testing exercise. The testers thus need to
– While Planning Tests
o Ensure covering all workflows in terms of decision trees in the code
o Ensure covering all data values – by identifying patterns rather covering millions of values
– While testing
o Ensuring the testing is completely exercising the whole application with planned and exploratory tests.

At the end of testing, the decision to stop testing and release the product still remains subjective, based on the presence or absence of bugs, inflow of new bugs, success rate of each test cycle, confidence rating of the testers or users, etc. Whereas the definitive metric of quantifying how much of the application was really tested, is missed.

Code Coverage is measured as quantification of application code exercised by the testing activities. Code Coverage can be measured at various levels – in terms of programming language constructs – Packages, Classes, Methods, Branches or in terms of physical artifacts – Folders, Files and Lines. For Eg. A Line Coverage metric of 67% means the testing exercised 67% of all executable statements of the application. A Code Coverage metric usually is accompanied by Code Coverage Analysis Report – which helps identify the un-tested part of the application code, thereby giving the testers early inputs for complete testing.

Benefits of Code Coverage

  • Objective Indicator of Test Coverage of application code
  • Pointers to uncovered Packages / Classes / Methods / Branches
  • Pointers to uncovered Folders / Files / Lines
  • Drill down to untested part of source code and devise new tests
  • Early Indicator for Testing Quality and Fixing it by adding new tests.
  • Remove redundancy in testing
  • Increased Confidence for Releases

Test Your Test

Typical Emotional Storyboard

  • Write Some code! Happy!
  • Does it work? Sad!
  • Write some test! Happy!
  • Do they really test the code? Sad!
  • Measure the Code Coverage! Happy!

Coverage Measurement

  1. Shows Which line of code are executed
  2. How much of your code is covered by your tests?
  3. Your tests test your product
  4. Coverage testing tests your tests


  • 100%
  • Coverage Ideal
  • Not Always possible
  • Can be expensive to achieve
  • Design for testability

Good: Write more tests
Only way to truly increase code coverage

Excluding Code to boost Coverage

Types of Coverage

  1. Statement Coverage
  2. Branch Coverage
  3. Path Coverage
  4. Loop Path Coverage
  5. Data – driven Code
  6. Complex Conditionals
  7. Hidden Branches

How; – Coverage Tools

  1. Clover
  2. Cobertura
  3. Emma
Tagged : / / / / / / / / / / / / /

Overview of EMMA | Code Coverage Tool – EMMA


EMMA is a tool for measuring coverage of Java software. Such a tool is essential for detecting dead code and verifying which parts of your application are actually exercised by your test suite and interactive use.
EMMA’s design strives for several, very elusive in their combination, goals:

  • report rich coverage analysis data without introducing significant overhead during either build or execution time
  • be useful in team development environments, while at the same time enabling fast individual develop-test cycle
  • support quick development and testing of small standalone Java applications as well as scale up to massive enterprise sotfware suites containing thousands of Java classes

Advantages of Emma over other coverage tools

EMMA differs from other coverage tools in its extreme orientation towards fast iterative develop-test style of writing software. JVM Profiler Interface (JVMPI)-based tools do not require an instrumented source build, but the runtime overhead of running with JVMPI on is empirically known to be very high and results in depressingly slow testsuite runs. For tools based on source code instrumentation, having to wait for a full source code rebuild just to check coverage metrics is not something a normal developer wants to do several times during a day. EMMA’s goal is to be so unintrusive that frequent daily checking of coverage numbers becomes second nature to every developer on the team, if not a completely automatic byproduct of every test run.

Install and Configuration

Method 1: To run on Command Line.
Copying emma.jar to <your jre dir>/lib/ext/ directory for whichever JRE you use from command line.
Method 2:
Still, if you are wary of adding a third-party library as a standard JRE extension, just make sure that all your EMMA command line invocations add emma.jar to the JVM classpath:
>java -cp …/lib/emma.jar <emma or emmarun command>

Implementing EMMA with Application

  • On the Fly Mode – Based suited for Standalone Application
  • Offline Mode – Best suited for J2EE framework based application

Implement EMMA in J2EE project {WebLogic, Websphere, Tomcat, JBoss, …}?

There are very less opportunities given by Emma that  you would be able setup emma for J2EE Project on the fly mode. The reason behind this to fact that many J2EE features requires specialized class loading that will happen outside EMMA instrumenting class holder. The server might run fine but you will unlikely to get EMMA report.
So, based Procedures to Instrument your classes prior to deployment (offline mode); offline instrumentation always follows the same compile / instrument / Package / deploy / get coverage / Generate report sequence.
There are following steps need to follow to implement EMMA in J2EE based project…

  • Use EMMA’s instr tool to instrument the desire classes. This can be done a post compilation step, before packaging. However many users also find it convenient to let EMMA process their jars directly (either in place, using overwrite mode, or by creating separate instrumented copies of everything, fullcopy mode.
  • do your J2EE packaging as normal, but do not include emma.jar as a lib at this level, that is, within your .war, .ear, etc;
  • locate whichever JRE is used by the container and copy emma.jar into its <jre dir>/lib/ext directory. If that is impossible, add emma.jar to the server classpath (in a server-specific way);
  • deploy your instrumented classes, .jars, .wars, .ears, etc and exercise/test your J2EE application via your client-side testcases or interactively or whichever way you do it;
  • to get a coverage dump file, you have three options described. It is highly recommended that you use coverage.get  control command with the ctl tool available in v2.1.



Emma Integration with other tools

Emma Integration with Sonar
Emma Integration with Hudson
Emma Integration with CruiseControl

jar instrumentation using Emma


Tagged : / / / / / / / / / /