...

The Parasoft Application Coverage solution enables you to measure application code coverage while executing tests against your running applications.  This You can collect coverage from a single running application or from an application that is made up of multiple backend services (you can collect coverage from all of them during execution of the same test cases). This enables you to gauge the effectiveness of your existing test suite, determine where additional tests need to be added, and more efficiently execute tests as the application evolves. You can collect application coverage by utilizing the coverage agent shipped with Parasoft Jtest and Parasoft dotTESTSOAtest for Java, which allows you to monitor the application as tests are being performed.

Application coverage is obtained by merging collecting and uploading static and dynamic (runtime) coverage data into one coverage file and uploading the file to DTP for viewing.

• Static Static coverage data is collected by Parasoft Jtest or Parasoft dotTESTa description of all source code that is available in your application. Static coverage files can be created by using Jtest or dotTEST to analyze the project's source code or using the coverage tool shipped with SOAtest to analyze the application binaries.
• Runtime coverage data is collected by SOAtest.
• Both coverage types are merged and uploaded to DTP by SOAtest. Data can be merged on DTP as needed.

The following steps describe the Application Coverage workflow with SOAtest:

1. Generating the static coverage file. The You can create static coverage files using in two ways:
   • When you have access to the application source code, the static coverage file
   is
   • should be generated by Jtest or dotTEST in
   the
   • .xml or .data format
   and contains
   • . It will contain metadata about user classes, methods, and lines. This is the preferred method.
   • When you only have access to the application binaries, generate the static coverage file with the coverage tool shipped with SOAtest.
2. Attaching the coverage agent to the application under test (AUT). The coverage agent ships with Jtest and dotTEST, and SOAtest and allows you to monitor the code being executed when the AUT is running.
3. Configuring SOAtest to connect to the coverage agent and collect runtime coverage, merge it with static coverage, and coverage and upload the data to DTP.
4. Executing tests with SOAtest as part of an automated process.
5. Reviewing the application coverage on DTP in the Coverage Explorer.

...

Before you start collecting coverage with SOAtest, you may need to configure the application under test (AUT) using Parasoft dotTEST or Parasoft Jtest. Note: if you are only analyzing the application binaries with the coverage tool shipped with SOAtest, this is not necessary. For details how to perform the following steps, see the Jtest or dotTEST user guide at docs.parasoft.com. Ensure that your SOAtest, dotTest, and JTest versions are in sync to avoid unexpected issues. This is the preferred method as it supports showing source code annotated with coverage data when viewing coverage results in DTP, which is not supported by just analyzing the application binaries.

1. Generate a static coverage file on a build machine. The file contains metadata about user classes, methods, and lines.
2. (Optional) Customize the coverage agent by configuring the coverage agent options. This step is required if you are collecting coverage information for multiple users that are simultaneously interacting with the AUT. 
3. Attach the coverage agent to the AUT.

...

• build.id: Set to the build ID with which to correlate coverage results. If you want to merge SOAtest coverage results with results from other types of testing—such as unit testing and manual testing of the same application—they must all use the same build ID. The build ID set here must match the build ID set for dotTEST or Jtest when collecting the static and dynamic coverage files and uploading the coverage data.
• dtp.project: This value must match the dtp.project value set for dotTEST or Jtest when collecting the static and dynamic coverage files.
• report.dtp.publish: Set to true to enable publishing test result data to DTP.
• application.coverage.enabled: Set to true. This enables application coverage.
• application.coverage.agent.url: Specify the URL where the application under test and coverage agent are hosted. Include the protocol (HTTP/HTTPS) and port number of the agent. Separate multiple entries with a semi-colon ( ; ). For example: http\://<Agent Host>\:8050;http\://<Agent Host>\:9050.
• application.coverage.user.id: Optional. Specify a user ID so that coverage results can be associated with a specific user. A user ID should only be specified when the coverage agent is configured to run in multi-user mode. See the DTP Engine documentation for details jtest.agent.enableMultiuserCoverage below.
• application.coverage.dtp.publish: Set to true to upload coverage reports to DTP or false to not upload coverage reports to DTP. If you have configured multiple coverage agents, their coverage reports will be merged into a single coverage report for DTP. Defaults to the value of report.dtp.publish (see Configuring Settings) or to true if -publish is passed to soatestcli.
• application.coverage.binaries: Optional. Specify the URL or local file that contains binaries of the application under test (AUT). You can specify the path to a folder or a .war, .jar, .zip, or .ear file. OptionalNot needed if the static coverage file is uploaded to DTP separately. Do not use if application.coverage.static.file has been specified.
• application.coverage.binaries.exclude: Optional, but recommended. Specify a comma-separated pattern of application binaries to exclude during AUT scanning. Optional. Do . If neither this nor application.coverage.binaries.include is configured, analysis of binaries will take longer and analyze more of the application than needed. Do not use if application.coverage.static.file has been specified. By default,  all all binaries are accepted. For example, application.coverage.binaries.exclude==jakarta/**,java/**,javax/**,org/apache/**,org/springframework/**
• application.coverage.binaries.include: Optional, but recommended. If neither this nor application.coverage.binaries.exclude is configured, analysis of binaries will take longer and analyze more of the application than needed. Specify a comma-separated pattern of application binaries to include during AUT scanning. Optional.   Do not use if application.coverage.static.file has been specified. By default,  all all binaries are accepted. For example,  application.coverage.binaries.include=com/myapp/data/*,com/myapp/common/**
• application.coverage.static.file: Optional. Specify the path to the static coverage file generated with dotTEST or Jtest in the .xml or .data format, or by the SOAtest coverage tool that analyzed the application binaries. Not needed if the static coverage file is uploaded to DTP separately. Do not use if application.coverage.binaries has been specified.
• application.coverage.images: Specify a set of tags that are used to create coverage images in DTP. A coverage image is a unique identifier for aggregating coverage data from runs with the same build ID. Separate multiple entries with a semi-colon ( ; ). For details, see the Parasoft DTP user guide. For example: ${dtp_project};${dtp_project}_Functional Test.

...

jtest.agent.serverEnabled=true
jtest.agent.includes=com/myapp/data,com/myapp/common/**
jtest.agent.excludes=com/myapp/transport/*,com/myapp/autogen/**
jtest.agent.associateTestsWithCoverage=true
jtest.agent.autostart=false

Coverage Agent Parameters

...

Run your tests in command line mode using the Test Configuration and settings file you have configured (see Configuring SOAtest to Collect and Upload Coverage). This step should be part of an automated process. Coverage data will be collected as tests execute and, if publishing to DTP has been enabled, uploaded to DTP.

Reviewing Coverage in DTP

...