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.

The post Top 5 Code Coverage Tools | Best Test Coverage Tools appeared first on scmGalaxy.

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

%JAVA_HOME%/jre/lib/security

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

%JAVA_HOME%/jre/lib/ext

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”

The post Clover and Maven working with Distributed Applications appeared first on scmGalaxy.