JCov 2.0 Tutorial |
This tutorial describes some typical methods for using JCov to get and analyze code coverage information for Java. It covers the following topics:
This tutorial demonstrate the typical usage of JCov, including different ways to receive code coverage data using JCov, and some JCov features that give more useful information about tested code. The procedure to receive code coverage information for any product contains 3 general steps:
Component | Description |
---|---|
tutorial | JCov tutorial, consisting of the following: |
Tutorial.html |
Short user guide how to start work with JCov tool. |
tutorial.build.xml, tutorial.build.properties |
The file
|
/doc |
Documentation directory. |
/example |
There is |
/src |
Source files for simple demo application (the application could count area of figures on the plane). |
/test |
Source files for tests to verify the demo application functionality. |
The tutorial contains basic steps which are discussed in their own section as follows:
Examples
ant
in the tutorial
directory:
ant -f tutorial.build.xml
DEMOAPP_BUILD
directory with all jcov examples for this application. The tutorial.build.properties
file contains properties which are used in building the demo application and running jcov examples. This simple demo application allows users to create two types of figures (square and disc); add these figures to the plane, and count the area of the figures on the plane depending on their color. There are two tests in the directory test
(TestDemoApp1, TestDemoApp2
) for this demo application. All the JCov examples will show how to receive code coverage data for this demo application - which describes how well the demo application is covered by these tests.
example#
directories in the created DEMOAPP_BUILD
directory. Each of these directories contains a build.xml
file for independent JCov examples. Execution of the ant
command (in the corresponding example#
directory):
ant -f build.xml
coverage
directory in the example#
with the code coverage report for the executed tests.
instrumenting the application
java -jar jcov.jar instr -t template.xml -o instr_classes $path_to_classes
starting a grabber to receive code coverage results
java -jar jcov.jar grabber -t template.xml -o result.xml
(separate process)
running tests
(as usual just adding jcov_network_saver.jar in classpath)
saving code coverage results (stopping the grabber)
java -jar jcov.jar grabbermanager -kill
generating report for received code coverage results
java -jar jcov.jar repgen -o report result.xml
static_instr.xml
file. These are the same steps that can be executed from the command line.
The static instrumentation may be generally easier to setup for complicated cases (eg. loading large API sets, things that require a large set of Java classes to be loaded). Static instrumentation typically adds only minor overhead on test execution.
javaagent
is used. In this case, application classes will be instrumented on loading, and a template.xml
file is created in memory. This example is using JCov dynamic instrumentation:
generate template
java -jar jcov.jar tmplgen -t template.xml $path_to_classes
(this step is needed to include unmodified application classes to the final code coverage report)
start the grabber to receive code coverage results
java -jar jcov.jar grabber -t template.xml -o result.xml
(separate process)
run the tests
adding javaagent option: "-javaagent:jcov.jar=grabber"
save the code coverage results (stopping the grabber)
java -jar jcov.jar grabbermanager -kill
generate the report for received code coverage results
java -jar jcov.jar repgen -o report result.xml
dynamic_instr.xml
file, the same steps could be executed from the command line. The dynamic instrumentation is good for small and simple cases (eg. small apps, limited API, things that don't require a large set of Java classes to be loaded). Without the tmplgen
command the report will not include unused classes in dynamic mode.
instrument the application
java -jar jcov.jar instr -t template.xml -o instr_classes $path_to_classes
run tests
(adding jcov_file_saver.jar in classpath, setting jcov.template and jcov.file properties)
generate a report for received code coverage results
java -jar jcov.jar repgen -o report result.xml
static_instr_file.xml
file, the same steps could be executed from the command line.
'one command'
feature to get coverage data without understanding any JCov inner processes. For this, a user needs to specify the application classes and the command to run tests:
get coverage for tests using one jcov command
java -jar jcov.jar jcov -pro $path_to_classes -out report -command "java -cp jcov_network_saver.jar MainTestsExecuter"
one_command.xml
file, the same steps could be executed from the command line.
instrument, grabber, grabber-manager
or report
tasks, a user needs to add JCov tasks in the application build.xml
file:
<taskdef name="jcovTasks" classname="com.sun.tdk.jcov.ant.AllTasks" classpath="jcov.jar"/>
jcov_ant_tasks.xml
file.
instrument the application
java -jar jcov.jar instr -t template.xml -o instr_classes $path_to_classes
start the grabber to receive code coverage results with tests information
java -jar jcov.jar grabber -t template.xml -outtestlist testlist.txt -o result.xml
(separate process)
run the tests
(adding jcov_network_saver.jar in classpath, setting jcov.testname property for each test)
save code coverage results (stopping the grabber)
java -jar jcov.jar grabbermanager -kill
generate a report for received code coverage results with tests' information
java -jar jcov.jar repgen -o report -tests testlist.txt -testsinfo -src $path_to_src result.xml
jcov_scales.xml
file, the same steps could be executed from the command line.