Knowledge Base > Cover CLI > User Manual

Diffblue Cover CLI User Manual

This is the User Manual for Diffblue Cover CLI commands. Please see the Getting Started information if you need help with installation and initial setup.

Commands
Default argument files
The -g option
Activating a license and viewing license details
Cover Reports commands
The create command
Additional optional arguments for create
The clean command
Additional optional arguments for clean
The validate command
Additional optional arguments for validate

Commands

Invocations of dcover take a subcommand, e.g. create, clean or help.

Command lines can become very long when many options are passed. Some terminals, such as those in Windows, do not support such long command lines, so Diffblue Cover CLI allows options to be imported from a plain text file with an arbitrary name, e.g. config.txt. This file can then be passed to the tool by adding the option @config.txt.

For example:

dcover create @config.txt

Options passed in this way can be added to the file one per line or separated by a space on the same line. Comments can also be added to the file.

Example configuration file:

--verbose --batch
--patch-only 'C:\Users\My User Name\myproject\patch.diff'
# We don't want to create tests for this class (this is a comment).
--exclude a.class.i.want.ToIgnore.

If you’re using this feature under PowerShell, typically on Windows, you might hit the error:

The splatting operator ‘@’ cannot be used to reference variables in an expression.

In this case make sure that you quote the configuration file to stop PowerShell from trying to interpret the @ symbol:

dcover create '@config.txt'

Default argument files

If you have a certain set of arguments that you frequently use with a command, you can add them to plain text files in the following locations instead of using the @ notation on the command line:

.diffblue/create.args
.diffblue/upload.args

This will allow you to run a command with common arguments, without having to repeatedly specify them on the command line

These files are command-specific, so any arguments added to .diffblue/create.args will only affect the dcover create command and likewise any arguments added to .diffblue/upload.args will only affect the dcover upload command. Without these files in the particular location, all desired arguments will have to be specified when running the relevant command.

Arguments added to these default configuration files can be overriden by specifying them, either on the command line or in a separate config file denoted by @config.txt. For example, assuming you had the following arguments in your .diffblue/create.args file:

--class-name-template "\${CLASS_NAME}Test"
--coverage-reports

You would be able to override these values by specifying them like so: dcover create --class-name-template="\${CLASS_NAME}DiffblueTest" --coverage-reports=false.

It should be noted that mutually exclusive parameters cannot be overriden. As a result, if you add these parameters to your default argument file, you will need to temporarily move or rename the file to be able to specify a different value. Currently, the following parameters are mutually exclusive:

--maven and --gradle

The -g option

The -g option (which is on in Maven, by default) is needed for Diffblue Cover to write the best tests possible. If you have switched off the -g option, please switch it back on again.

For Maven documentation, please see: http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#debuglevel

For Gradle documentation, please see: https://docs.gradle.org/current/dsl/org.gradle.api.tasks.compile.CompileOptions.html#org.gradle.api.tasks.compile.CompileOptions:debug

Activating a license and viewing license details

Usage: dcover activate $LICENSE

Using dcover requires a license to be activated before you are able to write tests. For pricing information, please see: https://www.diffblue.com/pricing/. When you activate a license you’ll see a summary of the license details printed to the console:

❯ dcover activate $LICENSE
INFO  Diffblue Cover 2021.08.03-SNAPSHOT-0bce711
INFO  Successfully activated key $LICENSE
INFO
INFO  License type: Enterprise Edition
INFO  License key: $LICENSE
INFO  License registered to: John Smith, john.smith@example.com
INFO  Available features:
INFO    Feature Batch Mode is neither time nor consumption limited
INFO    Feature CLI is neither time nor consumption limited
INFO    Feature Test Creation is limited to 2147483647 tests daily; you have used 0 of your current budget so far
INFO    Feature Patch Mode is neither time nor consumption limited
INFO    Feature Plugin is neither time nor consumption limited
INFO    Feature Replay is neither time nor consumption limited
INFO    Feature JSON Report is neither time nor consumption limited
INFO    Feature Cover Reports Analytics is neither time nor consumption limited
INFO    Feature Cover Reports Basic is neither time nor consumption limited
INFO
INFO  To start, run "dcover create" in a module of your project, giving it the
INFO  fully-qualified name of a package, class, or method.
INFO
INFO  For example:
INFO    dcover create com.example.
INFO    dcover create com.example.FooClass
INFO    dcover create com.example.FooClass.method
INFO
INFO  For help with running commands "dcover help" will show you all the
INFO  sub-commands, "dcover create --help" will show you help specific to the
INFO  sub-command "create".
INFO
INFO  See the Getting Started guide
INFO  https://docs.diffblue.com/getting-started/cli/basic-concepts

If you ever need to see the information about your license (e.g. the type of license, the number of tests remaining, which features are available to you), you can get this same summary by running dcover license.

Cover Reports commands

Usage:

dcover create --coverage-reports
--report <URL of Reports server>
--project <projectname path>
--name <name of report>

This command allows reports to be both created and uploaded to Diffblue Cover Reports.

If the --report argument is omitted, the report will not be displayed
If the --project argument is omitted, the report will go into the root of Reports and be marked as “orphaned”
If the --name argument is omitted, the report will be uploaded using the timestamp rather than a name.

You can also upload existing reports (jacoco.xml and dcover.json) using the dcover upload command:

dcover upload <URL of reports server>
--project <projectname path>
--name <reportname>

For example:

dcover upload http://reports.internal.customer.com:8080
--project customer-markets.name1.name2.name3
--name "Branch: 0123/feature-TG12345"

The create command

Usage: dcover create

By default, dcover automatically discovers all the packages and writes tests for all of them. You can tell dcover to only write tests for specific packages, classes or methods by specifying one or more prefixes. dcover matches prefixes against the fully qualified method names with descriptor.

Package example

dcover create com.a.. This will produce tests for all accessible methods within package com.a. and subpackages. For example, tests will be written for class com.a.B andcom.a.b.C but not for com.x.Y. Note that com.a (not com.a.) will allow tests to be written for class com.apple, com.apricot etc.

Class example:

Given two classes io.diffblue.corebanking.account.Account and io.diffblue.corebanking.account.AccountException:

dcover create io.diffblue.corebanking.account.Account

will create tests for both classes but:

dcover create io.diffblue.corebanking.account.Account. (note trailing .)

will create tests for the Account class only.

Method example:

dcover create io.diffblue.corebanking.account.Account.addToBalance: (note trailing :)

will create tests for all methods named addToBalance, e.g. addToBalance(int value) and addToBalance(double value), but not addToBalanceDeferred(int value). In order to write tests for addToBalance(double value) only, but not for addToBalance(int value), you also have to specify the method descriptor:

dcover create 'io.diffblue.corebanking.account.Account.addToBalance:(D)V'.

The method descriptor is a list of type descriptors in a single string, that describe the parameter types and the return type of a method. As in the example above, the type descriptor (D for double) is enclosed within parentheses, followed by the type descriptor of the return type OR a V if the method returns void. For more information on type descriptors and method descriptors, please see sections 2.1.3 and 2.1.4 of the ASM 4.0 A Java bytecode engineering library.

Note:

The descriptor is separated from the method name by :.
You can also specify a list of prefixes to ignore, using the --exclude option (see below).

Additional optional arguments for create

This is a list of the most common options, to see the full list of available options run dcover help create.

act-into-assert	active-profiles	annotate-suppress-warnings	arrange-into-act-assert	batch	build-system-configuration
class-name-template	classpath	compliance-level	cover-all-enums	coverage-reports
define	environment	disable-mock-inputs	disable-security-policy	exclude	existing-coverage
gradle	ignore-stylechecks	jacoco-command-diffblue	jacoco-command-manual	maven	merge
method-name-template	mock	output-comments	patch-only	preflight	report-file
skip-test-validation	spring-integration-tests	test-output-dir	testing-framework	validation-command	validation-timeout
verbose	working-directory

act-into-assert

Usage: --act-into-assert

Use this formatting option file to move execution of the MUT (method under test) from the act section into the assert section. This means there will not be an act section in the test(s) produced, and the MUT (normally within the act section) will now be run within the assertion statement in the assert section.

active-profiles

Usage: --active-profiles

Example: --active-profiles=development, --active-profiles=development,test

Use this option to specify any Spring profiles to activate while writing tests. You can specify multiple profiles by giving a comma separated list of profiles. By default, or if you do not specify this option, the default Spring profile will be used. Please see this separate page for further details.

allow-jni

Usage: --allow-jni

Example: --allow-jni=mycustomjni, --active-profiles=jna

Use this option to specify any additional Java Native Interface (JNI) library name prefixes that should be usable within the execution sandbox when creating and evaluating tests. JNI library names are the strings supplied in calls to System.loadLibrary(String). By default only JDK provided libraries are allowed.

Please see JNI for more information about working with JNI libraries.

annotate-suppress-warnings

Usage: --annotate-suppress-warnings

A simple way to turn off the warnings given by SonarQube is to use the --annotate-suppress-warnings option to add the @SuppressWarnings code annotation to all test methods written by Diffblue Cover.

For example:

--annotate-suppress-warnings=all

suppresses all SonarQube warnings by producing the code annotation:

@SuppressWarnings({"all"})`

If you want to turn off a specific warning, you can use the warning code to do this. For example, to suppress warning java:S1161, enter the following:

--annotate-suppress-warnings=java:S1161

arrange-into-act-assert

Usage: --arrange-into-act-assert

Use this formatting option to move all the information from the arrange section into either the act or assert sections, depending on the specific case. This means that there will not be an arrange section in the test(s) produced. The arrange section normally sets all of the variables and objects needed to run the MUT (method under test) and these will be inlined in the act section (when the MUT is run) or will become part of the assertion (in the assert section).

batch

Usage: --batch

Use this option to run dcover non-interactively, e.g. in CI, in order not to clutter the CI logs with progress bar output.

build-system-configuration

Usage: --build-system-configuration

Example: --build-system-configuration=~/.m2/settings.xml

Use this option if you want dcover to use a custom configuration file when interacting with the Maven build tool.

class-name-template

Usage: --class-name-template

Example: --class-name-template=\${CLASS_NAME}Test, default: --class-name-template=\${CLASS_NAME}DiffblueTest

Specifies how to name the test class files that are created. The variable ${CLASS_NAME} will be substituted with the name of the class under test. The $ must be escaped.

For example, with the argument given above, and a class name Foo, the name of the class file created will be FooTest.java. If this argument is specified without the variable ${CLASS_NAME}, all of the tests will be put into one file named by the string in the argument.

classpath

Usage: --classpath or -cp

By default dcover automatically determines the classpath for your project from Maven or Gradle. For projects where that isn’t possible, you can set the classpath with this option. For example:

-cp "target/classes:~/.m2/repository/junit/junit/4.12/junit-4.12.jar"

Provide the classpath(s) of the project you want to write tests for. Multiple paths can be specified using : as separators for Linux/macOS and ; for Windows. jar files can also be added to the classpath as shown above.

Please note that on Windows the classpath argument -cp must be wrapped in double quotes.

If this argument is used, you must ensure JUnit (and any other dependencies required to run the project’s unit tests) are on the classpath in order for the tests to be validated.

compliance-level

By default, dcover automatically determines the Java compliance level (“Java version”) being used. You can set it explicitly with this option.

Usage: --compliance-level

Example: --compliance-level=[3-13], default: --compliance-level=8

Specifies the Java Compiler Compliance Level (as an integer). Versions 3 to 13 are supported. The default value is 8.

Class files compiled on a newer version of the Java Compiler may not run on older versions of the JVM. This flag can be set to force the compiler to write class files corresponding to the specified Java version.

Use this argument if your project is designed to be compiled against a specific Java version other than your default.

cover-all-enums

Usage: --cover-all-enums

If specified, dcover will attempt to write tests using all possible values for Enum types used as a parameter, or to write test cases that cause the method-under-test to return all possible values of Enums. (This will happen even if this provides no additional measured coverage.)

coverage-reports

Usage: --coverage-reports

If specified, dcover will create coverage reports for Diffblue Cover Reports in /.diffblue/reports/. These two reports contain the coverage information for the manual (non-Diffblue) tests, and the Diffblue tests only.

This requires having JaCoCo set up in the project.

The JaCoCo command that is run by dcover can be configured using the --jacoco-command-manual and --jacoco-command-diffblue options which should run the non-Diffblue tests and the Diffblue tests, respectively.

Both Maven and Gradle are supported.

environment

Usage: --environment

Examples:

--environment KEY=VALUE

Define additional environment variable for this dcover execution.

In more complex environments (like Spring) environment variables are commonly used for configuration.

User code under test will be executed with the given environment variables. These environment variables will also be forwarded to your build tool (Maven/Gradle) during test validation.

NOTE: If you are specifying environment variables for dcover you will need to add those environment variables to the test execution configuration of your build script. Otherwise tests created using those environment variables will fail.

define

Usage: --define or -D

Examples:

--Dkey1=value1 --Dkey2=value2 -Dkey3=value3

Define system properties for this dcover execution.

In more complex environments (like Spring) system properties are commonly used for configuration.

User code under test will be executed with the given system properties. These system properties will also be forwarded to your build tool (Maven/Gradle) during test validation.

NOTE: If you are specifying system properties for dcover you will need to add those system properties to the test execution configuration of your build script. Otherwise tests created using those system properties will fail.

For more detail about build tool configuration with system properties see the sections about Maven and Gradle.

disable-mock-inputs

Usage: --disable-mock-inputs

If specified, dcover will not attempt to create mock objects for use as input parameters. Specifying this option does not affect the creation of mock objects as specified by the mock option.

disable-security-policy

Usage: --disable-security-policy

Uses a more permissive security manager policy for the methods under test. Use with caution! This option allows execution of potentially unsafe code during test creation, which may change the file system. Existing files will not be changed or deleted, but new files may be created.

exclude

Usage: --exclude or -E

Examples:

--exclude com.x.y. --exclude com.x.y.Foo --exclude com.x.y.Foo.bar:()V

For excluding problematic methods from test creation. Any test method with a fully-qualified name starting with an exclusion pattern will be excluded. The union of methods matched by the arguments is excluded from the set of included methods.

The exclusion argument may be a package name (use trailing .) or a fully-qualified class or method name. You may specify a trailing method signature if differentiating between overloaded methods.

existing-coverage

Usage: --existing-coverage or -e

Example: --existing-coverage=target/jacoco.exec

Takes a path to a JaCoCo coverage report (“target/jacoco.exec” here) as an argument, so that dcover will write tests only for those lines of code which are not already covered by existing tests.

Note 1: if using the JaCoCo coverage, --merge must be used (otherwise the tests that produce the coverage, would be replaced!).

Note 2: there are known issues with PowerMock and JaCoCo that can interfere with the usage of this feature:

https://github.com/powermock/powermock/wiki/Code-coverage-with-JaCoCo

gradle

Usage: --gradle

For cases where you prefer which tool is used, this option tells Cover to use Gradle.

ignore-stylechecks

Usage: --ignore-stylechecks

Example: --ignore-stylechecks=true, default: --ignore-stylechecks=false

When set, dcover will suppress known style checking plugins (checkstyle, spring-javaformat) during test validation; style checks may prevent compilation or test execution. Currently only supported by Maven projects.

jacoco-command-diffblue

Usage: --jacoco-command-diffblue

Examples:

--jacoco-command-manual "mvn clean test jacoco:report -Dtest='*DiffblueTest.java'" --jacoco-command-manual "./gradlew test --tests=*DiffblueTest.java"

Default:

Maven: mvn clean test jacoco:report -Dtest='*DiffblueTest.java' Gradle: ./gradlew test --tests=*DiffblueTest.java

When run with --coverage-reports, sets the JaCoCo command to run to produce the JaCoCo report for the Diffblue tests.

Care must be taken when supplying the arguments on Windows for the Gradle command. Gradle interprets the value after --tests literally, if you include quotes, for example, it’ll include the quotes too. If you find that the gradle execution fails, you can add --info and --debug to the command to help. You will see the Gradle output in the Cover log file.

jacoco-command-manual

Usage: --jacoco-command-manual

Examples:

--jacoco-command-manual "mvn clean test jacoco:report -Dtest='!*DiffblueTest.java'"

--jacoco-command-manual "./gradlew clean test --tests=!*DiffblueTest.java"

Default (for Maven):

mvn clean test jacoco:report -Dtest='!*DiffblueTest.java'

When run with --coverage-reports, sets the JaCoCo command to run to produce the JaCoCo report for the manual (non-Diffblue) tests.

For Gradle:

maven

Usage: --maven

For cases where you prefer which tool is used, this option tells Cover to use Maven.

merge

Usage: --merge

Example: --merge=true, default: --merge=false

If enabled and the .java test file already exists, the created tests are inserted into the appropriate file. If the file already contains tests for the same method, then the existing tests will be kept and therefore the file will contain both the existing and newly-created tests.

If disabled, any existing .java test file will be overwritten and contain only the newly-created tests.

method-name-template

Usage: --method-name-template

Default: test\${INNER_CLASS_NAME}$\${METHOD_NAME}

Example: testCreated\${INNER_CLASS_NAME}\${METHOD_NAME}

Specifies how to name the test methods that are created. The variable ${METHOD_NAME} will be substituted with the name of the method under test. Similar to --class-name-template.

mock

Usage: --mock

Example: --mock io.diffblue.packagetomock io.diffblue.otherpackage.ClassToMock

dcover will mock classes that match the given prefixes using Mockito. Non-void, non-private instance methods are stubbed with when().thenReturn(). The class containing the method for which the tests are being created will not be mocked. The project configuration must contain a test dependency for Mockito.

output-comments

Usage: --output-comments

Example: --output-comments=false

By default, this option is set to true. Setting it to false prevents the inclusion of “Arrange”, Act” and “Assert” comments for these three sections of the tests.

patch-only

Usage: --patch-only or -p

Example: --patch-only=path/to/patch-file

By specifying a patch file, it is possible to create tests only for the code changes affected by the patch, i.e. classes in the patch or classes that call a class in the patch.

Use diff or a similar tool to create a patch file for your changes in your project, e.g. git diff origin/develop > file.patch.

For a multi-module project, generate the patch at the root of the project and provide the absolute path to the patch file, using --working-directory with the relative path to the module. The same patch file can be used for each module.

For a project without modules, or a project where tests will only ever be created for a single module, where --working-directory is not used, the relative path to the patch file for the project or module only may be used, e.g.

cd Module
git diff origin/develop --relative > file.patch

--patch-only accepts files in UTF-8 encoding. If using PowerShell on Windows, use the following command to get the patch in UTF-8 instead of the default UTF-16:

git diff origin/develop | out-file file.patch -encoding utf8

preflight

Usage: --preflight

Run all the project and environment checks that dcover usually runs for this command without executing the full process. For example, dcover create --preflight verifies whether the local environment and the project are in the best condition possible for dcover to create tests, without creating the tests yet. Similarly, dcover create --coverage-reports --preflight performs all checks necessary for creating tests as well as coverage reports. For further information, please see: Preflight checks.

skip-test-validation

Usage: --skip-test-validation

By default, created tests are compiled and executed to make sure they are correct, and only those which succeed will be kept. Sometimes this results in all the tests being deleted due to style checks failing (see --ignore-stylechecks above), and it increases test creation time, so it may be desirable to skip validation via this option. For test validation to work, JUnit must be on the classpath. Normally dcover automatically takes care of this, but if you are using a manual classpath don’t forget to add it.

spring-integration-tests

Usage: --spring-integration-tests

Tests created for Spring components will use mocking only for Repository dependencies. All other dependencies will be resolved by Spring directly. Not applied when creating tests for @Controller classes.

Spring Repositories are classes implementing org.springframework.data.repository.Repository or those annotated with org.springframework.stereotype.Repository.

test-output-dir

Usage: --test-output-dir or -d

Default: src/test/java

Example: --test-output-dir=src/test/diffblue

Location for the created tests relative to the working directory. Provide the relative path for the directory where created tests should be placed.

See working-directory below.

testing-framework

By default dcover automatically determines the version of JUnit in use by your project. If there are multiple versions available, dcover will ask you which one you want to use. The --testing-framework command is used to specify which version to use.

Usage: --testing-framework <testing framework and version>

Example: --testing-framework=junit-4.7

The supported values for this option are valid versions from junit-4.7 to junit-5.9 (including, in particular, junit-4.13 as a special case for JUnit 4.13 support), and the special values junit-4 (any JUnit 4) and junit-5 (any JUnit 5 or later).

If you choose to supply this option the classpath will be checked to see if that framework is available. If there is a mismatch between versions dcover will produce an error.

The default is: junit-4.8.2

validation-command

Usage --validation-command or -x

By default, dcover uses the standard Maven or Gradle test command to validate tests. You can override that with this option.

Maven:
- The command must be a standard Maven command to which the -Dtest option can be appended. The command should not already contain -Dtest.
- If dcover create is run from the root of a multi-module project, using --working-directory, there is no need to include the --file (or -f) option to the validation command. The validation command will be run from the directory specified in --working-directory.
- If no command is provided, “mvn test” is run if dcover detects a pom file in the working directory. When the command fails for a certain test method, dcover will revert the entire test class containing that method.
Gradle:
- The command must be a standard Gradle command invoking a Test task, which will produce JUnit XML reports, and to which the --tests option can be appended.
- The command must not already contain the --tests option.
- The command must have info logging enabled (for test validation to work correctly). This can be done by adding -i/--info to the command.
- If no command is provided, “gradle test” is run if dcover detects a Gradle project in the working directory. When the command fails for a certain test method, dcover will revert the entire test class containing that method.

Example:

--validation-command "mvn test"

The given command is executed after tests have been written, to make sure they do not break the build. Tests are removed if it returns a non-zero exit value.

All existing tests should pass the validation command before dcover is invoked; there should be no pre-existing compilation or test failures.

validation-timeout

Usage: --validation-timeout

Example: --validation-timeout=duration, default: --validation-timeout=30m

Specifies how long test validation may take before being cancelled.

Supported values:

A positive integer value with one of the following suffixes: h for hours, m for minutes, or s for seconds.

If 0 (zero) is specified, the test validation will not timeout.

verbose

Usage: --verbose

If enabled, prints more detailed log messages about the test writing process.

working-directory

Usage: --working-directory

Example: --working-directory=path/to/module

Sets the working directory for running dcover, enabling the user to run dcover for a particular module, for example, from the root of a project.

The clean command

Example:

dcover clean

The clean command removes test methods written by dcover that no longer compile due to changes in the project.

As with create, if the package prefixes following clean are omitted, dcover will infer the packages from the directory structure.

Additional optional arguments for clean

As in the create section above:

Optional arguments specific to `clean`:

failing

Deprecated, use dcover validate instead.

test-classes-dir

Usage: --test-classes-dir="target/different-test-classes-directory", default: Determined by build system.

Directory to where created tests are compiled. This is necessary if the directory is different than the build system default.

The validate command

The validate command removes both non-compiling and failing tests by running a Maven or Gradle command. Running dcover validate removes failing and non-compiling unit test classes if they end in DiffblueTest.

Examples:

dcover validate

Alternatively, the command can be used with extra options, for example:

dcover validate --validation-command="mvn test -Dtest='*DiffblueTest.java'"
This call to dcover validate runs the specified validation command mvn test -Dtest=*DiffblueTest.java and deletes any non-compiling or failing tests resulting from this command.