Sign In or Register
Not Registered Yet?

Join Now! It's FREE. Get full access and benefit from this site

Reset My password - Remind Me My username

Remember me
Test Coverage Tools

Test Coverage Tools (2)

Test Coverage Tools

Today we will talk about code coverage tools which are used by developers for measuring the quality of the software testing. There are so many different types of code coverage tools, some are basics and others that are exceptionally thorough.
But before going further on tools let's first see what is Code Coverage?
Code Coverage is a methodology, which is performed to measure and describe how much the source code of a program is executed when a specific test suite runs. It gives a percentage score to a program which defines as a high code coverage and low code coverage. If it gets high percentage of code coverage during testings which means it has a minimal chance of containing undiscovered software bugs in the comparison of a program which scored low percentage of code coverage while testing. In simple words , code coverage is performed to check whether your tests are really analyzing your code or not. With code coverage, one can tell the amount of your code is being tested by running the test.
Where to use ?
Code coverage tools can be performed on .NET, Java, Visual C/C++ and Visual Basic applications.
Benefits of Code Coverage
Dead Code Identification - The first and the major benefits of code coverage is that after running this test you will get the outputs that shows those functions which are not called, after detecting that you can identify whether the code is untouched as no required use case exists or code is dead code (i.e. not required).
Missing test Identification - It can be beneficial in identifying the extra tests (exceptional cases), which are missed out earlier after running the test suites analysis report.
Quality Assurance - Quality of a product or application is one of the major concern in software world and this can be done by measuring the report after running the code coverage. Higher the amount of coverage better will be the quality of product or application and lesser is the chance to have defects.
Now the next question here is which code coverage tools to choose ?
This is the real challenge to choose which code coverage tools to use for application testing. I also thought about it and after few hours research on the internet and with the help of google trend I shortlisted my results and pick top 5 code coverage tools.
1. Cobertura -

Cobertura is one of the most used and best code coverage tools. This is a free Java tool that calculates the percentage of code accessed by tests. It can be used to identify which parts of your Java program are lacking test coverage. It is based on jcoverage. It is easy to use and can measure coverage without having the source code. It's represents reports in HTML or XML format, It has capacity to test lines and branches of class and method.
2. JaCoCo -

JaCoCo is also an open source free code coverage tools for Java, which has been made by the EclEmma group in view of the lessons gained from utilizing and joining existing libraries for a long time. JaCoCo offers instructions, line and branch coverage. It can instrument off-line and on-the-fly and It fully supports Java 7 and Java 8. It also has capacity to test lines and branches of class and method. It also provide very nice and easy to navigate HTML or XML report.
3. Clover -

Clover is also a Java Code Coverage tools bought and further developed by Atlassian. It is also an open source tool. Clover provide very helpful configurable HTML reports demonstrating code scope as well as high level risks and so on, per-test code coverage and test enhancement, dispersed per-test coverage and many instrument integration; it is by and large effectively created and supported.
4. NCover-

NCover is a code coverage tool for .Net programs and applications. It supports statement coverage and branch coverage. It is also very easy to use and fast tool which is available on open source and as well as on commercial license. This tool can perform manual as well as automated code coverage tests and it provides nice and attractive multiple testing environments.
5. Testwell CTC++ -

Testwell CTC++ is a code coverage tool for  C and C++ but it also can be used for Java and C#. The development of this tool is belongs to Testwell which lately acquired by Verifysoft Technology GmbH for C and C++. This tool can check Statement Coverage, Function Coverage, Decision Coverage, Multi Condition Coverage, Modified Condition/Decision Coverage (MC/DC), Condition Coverage. This is also in the category of user-friendly and fast tools. It finds missing test cases smoothly. It provide reports on XML format.
So, This is my list of top code coverage tools, I hope this list will help you in your testings. But, if you think this list should contain any other tools instead these than feel free to share with us in comment box below.

1.       Configure maven clover plugin.

2.       Build the all components with clover enabled.

3.       Deploy the clover enabled build to test server.

4.       Run the tests.

5.       Create & Review the Code Coverage Report.

Configure Maven Clover Plugin

Configure the maven plugin in pom.xml .If you are having multi module projects; you can configure the plugin in parent-pom instead of modifying each module’s pom xml.


Build all components with clover enabled.

Run the following command.


  “mvn -U clover2:setup package clover2:aggregate


                If you got something like this

[INFO] Loaded from: C:\Documents and Settings\Administrator\.m2\repository\com\cenqua\clover\clover\2.6.3\clover-2.6.3.jar

[INFO] Clover: Commercial License registered to ABC Corporation.

[INFO] Creating new database at 'C:\p4_depot\trunk\4A\target\clover\clover.db'.

[INFO] Processing files at 1.5 source level.

[INFO] Clover all over. Instrumented 5 files (1 package).

[INFO] Elapsed time = 0.532 secs. (9.398 files/sec, 812.03 srclines/sec)

Congratulation, you get clover work with your source!!


Deploy the clover enabled build to test server.

Deploy the Clover enabled build to the server. The same process as normal

Copy the Clover registry file to the appropriate directory on each of the test servers


The registry file is the DB file create during compile, defined by initstring parametersclover‐setup task, this needs to occur after the Clover build is complete, and before you run your tests


Background: the Clover initstring


FileName: xxx.db

At build time, Clover constructs a registry of your source code, and writes it to a file at the location specified in the Clover initstring. When Clover‐ instrumented code is executed (e.g. by running a suite of unit tests), Clover looks in the same location for this registry file to initialise itself. Clover then records coverage data and writes coverage recording files next to the registry file during execution

Notes: gives the folder contains the registry file full control permissions


Recommended Permissions

Clover requires access to the Java system properties for runtime configurations, as well as read write access to areas of the file system to read the Clover coverage database and to write coverage information. Clover also uses a shutdown hook to ensure that it flushes any as yet unflushed coverage information to disk when Java exits. To support these requirements, the following security

permissions are recommended:


grant codeBase "file:/path/to/clover.jar" {

permission java.util.PropertyPermission "*", "read";

permission java.io.FilePermission "<>", "read, write";

permission java.lang.RuntimePermission "shutdownHooks";



Grant Permissions to clover.jar

Edit the java.policy file of the java runtime on the test server



Copy clover.jar and license file to the java runtime class path of the test servers




Run the test suite

Run the test suite as normal. Either automation test case or manual test case.


Create Code Coverage Report

Copy the coverage recording files to build machine.


Once test execution is complete, you will need to copy the coverage recording files from each remote machine to the initstring path on the build machine in order to generate coverage reports.


Background: CoverageRecording Files


Filename:xxx.dbHHHHHHH_TTTTTTTTTT or clover.dbHHHHHHH_TTTTTTTTTT.1 (where HHHHHHH and TTTTTTTTTT are both hex strings)

CoverageRecording files contain actual coverage data. When running instrumented code, Clover creates one or more Coverage Recorders. Each Coverage Recorder will write one CoverageRecording file. The number of Coverage Recorders created at runtime depends the nature of the application you are Clovering. In general a new Coverage Recorder will be created for each new ClassLoader instance that loads a Clovered class file. The first hex number in the filename (HHHHHHH) is a unique number based on the recording context. The second hex number (TTTTTTTTTT) is the timestamp (ms since epoch) of the creation of the Clover Recorder. CoverageRecording files are named this way to try to minimise the chance of a name clash. While it is theoretically possible that a name clash could occur, in practice the chances are very small.

CoverageRecording files are written during the execution of Clover‐instrumented code. CoverageRecording files are read during report generation or coverage browsing.


Run the generating report goal to create the report.

                                “mvn clover2:clover”



Why scmGalaxy is preferred for DevOps?

What our participants say?