# Discover Diffblue Cover

Diffblue Cover is a reinforcement learning AI platform that automatically writes comprehensive, human-like Java unit tests - saving developer time, increasing test coverage, and reducing regression risks. Cover is provided as an IntelliJ IDE plugin, a CLI application, and a CI integration to provide fully autonomous operation. Three additional components, for test management and analytics, complete the Diffblue Cover solution.

## Get started

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><mark style="color:blue;"><strong>What is Diffblue Cover?</strong></mark></td><td>Familiarize yourself with the features, functions, and capabilities of Diffblue Cover.</td><td></td><td></td><td><a href="/pages/JuNKt6UxiiRtm5c1hF39">/pages/JuNKt6UxiiRtm5c1hF39</a></td></tr><tr><td><mark style="color:blue;"><strong>Free-Trial</strong></mark></td><td>Trying out Diffblue Cover for the first time? Get up and running with Cover Plugin for IntelliJ and Cover CLI – download, install, license, and play.</td><td></td><td></td><td><a href="/pages/Xvlm09AC7hewEt2hEyyH">/pages/Xvlm09AC7hewEt2hEyyH</a></td></tr><tr><td><mark style="color:blue;"><strong>Get Started</strong></mark></td><td>Get started with Diffblue Cover, from your first AI-created Java unit test, to analyzing your code coverage, and more.</td><td></td><td></td><td><a href="/pages/wis75xStPSFZfJOiO1Bv">/pages/wis75xStPSFZfJOiO1Bv</a></td></tr></tbody></table>

## Discover the details

**Product specific:**

<table data-view="cards"><thead><tr><th data-type="files"></th><th></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td></td><td>Automatically write unit tests for your methods and classes directly in IntelliJ.</td><td><a href="/files/qGpBLOIO9gPrmoMRr93G">/files/qGpBLOIO9gPrmoMRr93G</a></td><td><a href="/pages/aBlglBGTz9yT4aMfQgJS">/pages/aBlglBGTz9yT4aMfQgJS</a></td></tr><tr><td></td><td>Automatically write unit tests for your project using the command line.</td><td><a href="/files/VjMtBUujqITa8iRFfnPm">/files/VjMtBUujqITa8iRFfnPm</a></td><td><a href="/pages/rBwz0R5WTHGiexiV5Lz5">/pages/rBwz0R5WTHGiexiV5Lz5</a></td></tr><tr><td></td><td>Integrate Cover CLI directly into your source code control / CI Pipeline.</td><td><a href="/files/0VFclbDpFPdm1eHwZPDM">/files/0VFclbDpFPdm1eHwZPDM</a></td><td><a href="/pages/kptlgnhrAIMMYlVy5yTS">/pages/kptlgnhrAIMMYlVy5yTS</a></td></tr><tr><td></td><td>Visualize and manage your test coverage.</td><td><a href="/files/FDMGAQ8RIdG3rC7aNHp7">/files/FDMGAQ8RIdG3rC7aNHp7</a></td><td><a href="/pages/9oHmWHdRWPnO6scWUlTO">/pages/9oHmWHdRWPnO6scWUlTO</a></td></tr><tr><td></td><td>Automatically refactor code to make it more testable and increase coverage.</td><td><a href="/files/Gdt5dtX4lijzpAMRj77y">/files/Gdt5dtX4lijzpAMRj77y</a></td><td><a href="/pages/M28Gc34PDVcj3maGMudY">/pages/M28Gc34PDVcj3maGMudY</a></td></tr><tr><td></td><td>Run only the unit tests that apply to your code change, reducing CI time and cost.</td><td><a href="/files/TCuFooajg0lcZ8UvcEgG">/files/TCuFooajg0lcZ8UvcEgG</a></td><td><a href="/pages/DCVAg420MgLaVstR35Fr">/pages/DCVAg420MgLaVstR35Fr</a></td></tr></tbody></table>

**General information:**

<table data-view="cards"><thead><tr><th></th><th data-hidden data-card-target data-type="content-ref"></th><th data-hidden></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th></tr></thead><tbody><tr><td><mark style="color:blue;"><strong>Specs &#x26; Reqs</strong></mark></td><td><a href="/pages/pDoeGe6cmbIF025UbKoh">/pages/pDoeGe6cmbIF025UbKoh</a></td><td></td><td></td><td></td></tr><tr><td><mark style="color:blue;"><strong>Output Codes</strong></mark></td><td><a href="/pages/NesTdPaeLWtiOqUPTgND">/pages/NesTdPaeLWtiOqUPTgND</a></td><td></td><td></td><td></td></tr><tr><td><mark style="color:blue;"><strong>Licensing</strong></mark></td><td><a href="/pages/66tpWR5RYATs6ph8klrg">/pages/66tpWR5RYATs6ph8klrg</a></td><td></td><td></td><td></td></tr><tr><td><mark style="color:blue;"><strong>Improve Code Coverage</strong></mark></td><td><a href="/pages/6i5bgxJLrSVm7AMrvNxw">/pages/6i5bgxJLrSVm7AMrvNxw</a></td><td></td><td></td><td></td></tr><tr><td><mark style="color:blue;"><strong>Update Cover</strong></mark></td><td><a href="/pages/XJfKHVwur3GJjn3DEEb9">/pages/XJfKHVwur3GJjn3DEEb9</a></td><td></td><td></td><td></td></tr><tr><td><mark style="color:blue;"><strong>Cover Editions</strong></mark></td><td><a href="/pages/DUfIj2mMIGyS3o0NPnTy">/pages/DUfIj2mMIGyS3o0NPnTy</a></td><td></td><td></td><td></td></tr></tbody></table>


# What is Diffblue Cover?

Diffblue Cover is a reinforcement learning AI platform that automatically writes comprehensive, human-like Java unit tests for Java and Kotlin projects - saving developer time, increasing test coverage, and reducing regression risks. Cover is provided as an IntelliJ IDE plugin (Cover **Plugin**), a CLI application (Cover **CLI**), and a CI integration to provide fully autonomous operation (Cover **Pipeline**). Three additional components (Cover **Reports**, Cover **Optimize**, and Cover **Refactor**), for test management and analytics, complete the Diffblue Cover platform.

But what does that mean in practical terms? As an example, let's take a method for uploading a file to an Amazon S3 bucket. The method is relatively simple, just a few lines of code, but the required test is more complex and would take a developer approximately 30 minutes to write if they've never done it before. Diffblue Cover did this in 1.6 seconds - that's not a typo - 1.6 seconds, computationally perfect, human readable, every pathway tested.

{% tabs %}
{% tab title="Method" %}

```java
    public PutObjectResult uploadFileToBucket(String bucketName, String key, File file) {
        try {
            return s3client.putObject(bucketName, key, file);
        } catch (AmazonS3Exception e) {
            throw new IllegalStateException("Totally handled this exception", e);
        }
    }
```

{% endtab %}

{% tab title="Unit Test" %}

<pre class="language-java"><code class="lang-java">@ContextConfiguration(classes = {AmazonService.class})
@ExtendWith(SpringExtension.class)
class AmazonServiceDiffblueTest {
    @MockBean
    private AmazonS3 amazonS3;

    @Autowired
    private AmazonService amazonService;

    /**
     * Method under test: {@link AmazonService#uploadFileToBucket(String, String, File)}
     */
    @Test
    void diffbluetestUploadFileToBucket() throws SdkClientException {
        // Arrange
        PutObjectResult putObjectResult = new PutObjectResult();
        putObjectResult.setContentMd5("MjdjN2NmNDAwMjI5MTAzZTAwYzZkODgzMDAyOWUyOWI=");
        when(amazonS3.putObject(Mockito.&#x3C;String>any(), Mockito.&#x3C;String>any(), Mockito.&#x3C;File>any()))
                .thenReturn(putObjectResult);

<strong>        // Act and Assert
</strong>        assertSame(putObjectResult, amazonService.uploadFileToBucket("bucket-name", "object-key",
                Paths.get(System.getProperty("java.io.tmpdir"), "test.txt").toFile()));
        verify(amazonS3).putObject(Mockito.&#x3C;String>any(), Mockito.&#x3C;String>any(), Mockito.&#x3C;File>any());
    }
}
</code></pre>

{% endtab %}
{% endtabs %}

Taking another real-world example from an existing customer we can illustrate how this is scaled up for an organization. Diffblue Cover was able to write 3,000 unit tests across an expansive code base for a single mission-critical application, right out of the box. A conservative estimate is that this would have taken a senior developer an estimated 268 developer days to write. Diffblue Cover achieved this in 8 hours, doubling test coverage, even before any refactoring.

<div align="left"><figure><img src="/files/fIIRtxreGVzYYGeCSIoJ" alt="" width="563"><figcaption></figcaption></figure></div>

## Some basics

If you missed our short intro video on the website, take a look here - this captures the essentials of Diffblue Cover:

{% embed url="<https://www.youtube.com/embed/9vt1szlaAKw>" %}

## Key features

Diffblue Cover is the generative AI engine at the center of our platform. Cover automatically writes human-like Java unit tests that are easy for a developer to read and understand. AI-written unit tests are ready to use - they compile, run, and accurately validate the current behavior of your code.

Cover is fully autonomous. It can create an entire unit test suite for your whole application in a single execution, run locally within your environment, no cloud service required, no developer overhead. Cover also maintains this unit test suite as your software evolves, even on applications with millions of lines of code. Thanks to a deep understanding of how your code works, Diffblue Cover knows what tests need to be added and updated for every code change. It implements the necessary updates automatically, ensuring coverage doesn’t dip while your teams move faster.

### IDE, CLI, CI Pipeline

Diffblue Cover is one AI, provided in three interaction models - an IDE plugin (Cover **Plugin**) and a CLI tool (Cover **CLI**) for developer use, and a CI Pipeline integration (Cover **Pipeline**) for DevOps teams. Use Cover Plugin, CLI, and Pipeline in isolation or in partnership as needed, depending on your preferred workflow.

{% tabs %}
{% tab title="Cover Plugin" %}

* Cover Plugin for IntelliJ writes tests for your methods and classes directly within the IDE on the developer desktop.
* One click test creation, fully integrated UI.

<div align="left"><figure><img src="/files/cxqhxCNkKtMhZMor4NwV" alt="" width="563"><figcaption></figcaption></figure></div>
{% endtab %}

{% tab title="Cover CLI" %}

* Advanced users may prefer the Cover CLI tool.
* More powerful, scriptable, and can generate tests for entire projects with a single command.
* Works 100% autonomously, configuring itself from your Maven or Gradle environment.
* Provides access to a wider feature set such as running preflight environment checks, creating coverage report bundles for use with Cover Reports, restricting test creation to code changes only, and more.

<div align="left"><figure><img src="/files/Vooa9eDJJxrUYFEpyeKy" alt="" width="375"><figcaption></figcaption></figure></div>
{% endtab %}

{% tab title="Cover Pipeline" %}

* Integrate the power of Cover CLI into your CI pipeline.
* Cover Pipeline creates and keeps your entire team's unit tests up-to-date within your GitHub, GitLab, Maven, Jenkins, Azure, AWS, or other CI pipelines.
* Each time a pull request is opened Cover can automatically create, execute, and update your unit test library at appropriate points in the process.
* The Cover Pipeline CI integration is the most scalable, reliable, repeatable option - unit testing becomes an effortless part of your workflow.

<div align="left"><figure><img src="/files/1unBcDyJHLkO92HZtQ7H" alt="" width="563"><figcaption></figcaption></figure></div>
{% endtab %}
{% endtabs %}

### Report, Optimize, Refactor

Three additional features are provided to allow you to monitor your test coverage (Cover Reports), optimize test runs (Cover Optimize), and automatically refactor your code to improve testability (Cover Refactor).

{% tabs %}
{% tab title="Cover Reports" %}

* Visualization tool for test coverage statistics, coverage risk, testability, and more.
* Get valuable insights about your Java codebase - pinpoint unique, actionable insights that improve quality and efficiency.
* Have a more holistic view of unit testing. Coverage data is combined with information on variables like code quality, testability. and complexity.
* Understand risk. Reports show you exactly what code isn’t tested, how important it is, and why tests might not have been written.
* Benchmark and track the effectiveness of your Java unit testing over time.
* Track how Diffblue Cover is being used across your organization.

<figure><img src="/files/YYaMHrYrQncvlEMkcUn4" alt=""><figcaption></figcaption></figure>
{% endtab %}

{% tab title="Cover Optimize" %}

* Selective unit test execution, integrated into Cover CLI and Cover Pipeline.
* Automatically selects only the unit tests required to fully validate that a code change hasn’t introduced regressions.
* Reduce developer waiting time, reduced cloud computing costs, optimized PR workflows.

<figure><img src="/files/XA376ZWUhWWdVzVnvYyP" alt=""><figcaption></figcaption></figure>
{% endtab %}

{% tab title="Cover Refactor" %}

* Automated code refactoring tool to improve testability and test coverage.
* Integrated into Cover CLI and Cover Pipeline.
* Cover Refactor can suggest and apply code refactorings that improve the observability of Java code and make it more testable.
* Better code, increased coverage, reduced regression risk.

<div align="left"><figure><img src="/files/eVgz5bAji2F5lSa7gESE" alt="" width="563"><figcaption></figcaption></figure></div>
{% endtab %}
{% endtabs %}

### Key benefits - in summary

It's difficult to summarize all the benefits of Diffblue Cover, but here's our top ten:

* **Automated Java unit tests.** This one's a given. Automatic, unbiased unit tests that exercise the actual behavior of your code, including obscure corner cases and scenarios developers may not know how to test.
* **Eliminate developer overhead.** Avoid researching tests, writing tests, maintaining tests, learning unfamiliar code source, context switching, waiting time, and more. Target your developer skills at improving your applications instead.
* **Catch regressions early** and at the most granular level. Avoid rework time, optimize workflows, and avoid outages in the field.
* **Increase coverage.** Get to 80% coverage in half the time! Diffblue Cover creates unit tests in bulk to help your team quickly assess the quality of your test suite.
* **Untangle legacy code.** Our tests document your code, making scary code changes easy. This helps you to quickly write tests for large legacy codebases, and identifies untestable code that should be refactored.
* **Reduce development costs** and **increase productivity.** With reduced or eliminated developer time, optimized test runs, CI/CD integration, and more, Diffblue Cover works 24/7.
* **Document your code.** Diffblue Cover unit tests describe every behavior of every method - effectively documenting your code to make future code changes quicker and reduce regressions.
* **Monitor coverage and understand risk.** Cover shows you exactly what code isn’t tested, how important it is, and why tests might not have been written. Target developer expertise more efficiently, either at areas of most risk or those where additional coverage can most easily be delivered.
* **Accelerate modernization and cloud migration.** Diffblue Cover can support the migration from applications to microservices by providing a documented code base and improved test coverage.
* **Keep code private.** Diffblue Cover’s generative AI operates entirely within your environment. No data ever leaves your organization.

## How it works

* Diffblue Cover first ensures that your code is compiled and examines each method that Cover will create tests for, and any related methods.
* Cover then creates initial test candidates for each method, which are then evaluated and adjusted to maximize test coverage. This process is repeated until the set of tests that optimize coverage are selected and committed to your code base. The tests are computationally correct and human readable, every time.
* Diffblue Cover is intended to be used for unit regression testing. That means it creates tests that reflect the current behavior of your code. Later, when you make changes to the code, these tests may fail and therefore highlight regressions. Since tests are written for your entire application at the most granular level, this means the smallest of regressions are caught which can avoid the dangers of incubated regressions that can manifest and build over time.

<div align="left"><figure><img src="/files/4VbARkXKkTu5MYjP2WsR" alt=""><figcaption></figcaption></figure></div>


# Get started

Get started with Diffblue Cover - Plugin, CLI, Pipeline, Reports.

<table data-card-size="large" data-view="cards"><thead><tr><th data-type="files"></th><th></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td></td><td><p><strong>Get Started - Cover Plugin</strong></p><p>Automatically write unit tests for your methods and classes directly in your IDE.</p></td><td><a href="/files/qGpBLOIO9gPrmoMRr93G">/files/qGpBLOIO9gPrmoMRr93G</a></td><td><a href="/pages/Ios2MK7nZhRtOElluf0u">/pages/Ios2MK7nZhRtOElluf0u</a></td></tr><tr><td></td><td><p><strong>Get Started - Cover CLI</strong></p><p>Automatically write tests for your entire project using the CLI tool.</p></td><td><a href="/files/VjMtBUujqITa8iRFfnPm">/files/VjMtBUujqITa8iRFfnPm</a></td><td><a href="/pages/7V85GXh1MOFovvH55h1E">/pages/7V85GXh1MOFovvH55h1E</a></td></tr><tr><td></td><td><p><strong>Get Started - Cover Pipeline</strong></p><p>Integrate Diffblue Cover directly into your CI Pipeline.</p></td><td><a href="/files/0VFclbDpFPdm1eHwZPDM">/files/0VFclbDpFPdm1eHwZPDM</a></td><td><a href="/pages/3PHH68CugYUJbDc64dmA">/pages/3PHH68CugYUJbDc64dmA</a></td></tr><tr><td></td><td><p><strong>Get Started - Cover Reports</strong></p><p>Visualize and manage your test coverage.</p></td><td><a href="/files/FDMGAQ8RIdG3rC7aNHp7">/files/FDMGAQ8RIdG3rC7aNHp7</a></td><td><a href="/pages/Bjd6iWnriOknF396pcNZ">/pages/Bjd6iWnriOknF396pcNZ</a></td></tr><tr><td></td><td><p><mark style="color:blue;"><strong>Free-Trial</strong></mark></p><p>Get up and running with your trial version of Cover Plugin <strong>and</strong> Cover CLI.</p></td><td></td><td></td></tr><tr><td></td><td><p><mark style="color:blue;"><strong>Update</strong></mark></p><p>Update your Cover Plugin and Cover CLI installs to the latest version.</p></td><td></td><td></td></tr></tbody></table>

{% hint style="info" %}
To get started with Diffblue's GitLab or GitHub integrations, see [Cover Pipeline for GitLab](/features/cover-pipeline/cover-pipeline-for-gitlab) or [Cover Pipeline for GitHub](/features/cover-pipeline/cover-pipeline-for-github).
{% endhint %}

> Demo code, statistics, and timings used throughout Diffblue docs and eLearning videos are based on in-house demonstrations. These may differ slightly from those experienced within a live production environment.


# Free trial

Diffblue Cover free trial step by step demo - Cover Plugin and Cover CLI

Trying out Diffblue Cover for the first time? Get up and running with the trial version of Cover Plugin for IntelliJ and Cover CLI – download, install, license, and play.

## eLearning

**Short on time?** If you'd like a fast-track experience check out our free trial experience video. \[7 min]

{% embed url="<https://youtu.be/CnDKtCrwnrI>" %}

## A few points first...

#### Cover components

Cover is provided as an IDE plugin tool so you can write tests with one click in the IntelliJ IDE (Cover Plugin), a CLI application to write tests for your entire project (Cover CLI), and a CI integration to automatically write tests within your CI workflow (Cover Pipeline).

#### Perfect partners

Cover Plugin, Cover CLI, and Cover Pipeline are not mutually exclusive, in fact they make perfect partners. Use Cover Plugin within the IntelliJ IDE to write and check unit tests for your application during development, and also use Cover CLI directly from the IntelliJ Terminal/Console or your OS command line to access the wider and deeper functionality provided by Cover CLI - finally, use Cover Pipeline within your CI tool to automate the whole process and provide consistency across your organisation.

#### The free trial

This topic focuses on Cover Plugin and Cover CLI, and will take you through the key steps to download, install, and license both tools, as well as covering a few basics and getting some tests written using each tool. Cover Pipeline for GitLab is also available as a free trial version, see [Cover Pipeline for GitLab](/features/cover-pipeline/cover-pipeline-for-gitlab) for details - for all other CI integrations please [contact](https://www.diffblue.com/contact/) Diffblue.

<div align="left"><figure><img src="/files/NA3hXyRgNV8MOqNxWrxQ" alt="" width="375"><figcaption></figcaption></figure></div>

## 1. Sign up

If you haven't already done so, sign up for the free trial - see <https://www.diffblue.com/try-cover>.

After successful sign-up, you'll receive a welcome email with general information and a license key for Cover Plugin and Cover CLI.

## 2. Install Cover Plugin for IntelliJ

You can install the Cover Plugin either from a downloaded ZIP archive or from the IntelliJ marketplace.

{% tabs %}
{% tab title="From a ZIP Archive" %}

1. Download the Diffblue Cover Plugin for IntelliJ as a `.zip` bundle from:\
   \
   \&#xNAN;**-** The Diffblue website - [Free Community Edition](https://www.diffblue.com/community-edition/download) or [Free Trial](https://www.diffblue.com/try-cover) versions.\
   \
   \&#xNAN;**-** The [JetBrains Marketplace](https://plugins.jetbrains.com/) (IntelliJ Plugin Marketplace).\
   \
   \&#xNAN;**-** The link sent to you via your Diffblue Cover welcome email.\
   \
   \&#xNAN;**-** Your organization's internal file/app store.\\
2. In the IntelliJ IDE, open the `Plugins` menu - either `File > Settings > Plugins` (Windows/Linux) or `IntelliJ IDEA > Preferences > Plugins` (macOS).
3. Click on the cog icon next to the `Installed` tab and select `Install Plugin from Disk...`. Navigate to the location of the plugin, select the zip file, and click `OK`.
4. When prompted, click `Restart IDE` to complete the install.

<div align="left"><figure><img src="/files/ycvubmiRG7vxeLQ2vK8C" alt="" width="266"><figcaption></figcaption></figure></div>
{% endtab %}

{% tab title="From IntelliJ IDE" %}

1. In the IntelliJ IDE, open the `Plugins` menu - either `File > Settings > Plugins` (Windows/Linux) or `IntelliJ IDEA > Preferences > Plugins` (macOS).
2. Select the `Marketplace` tab, search for `Diffblue`, and click `Install`. Your plugin will now be downloaded and installed.
3. When prompted, click `Restart IDE` to complete the install.

<div align="left"><figure><img src="/files/yZdmQKOSfbjavEKeQT2C" alt="" width="563"><figcaption></figcaption></figure></div>
{% endtab %}
{% endtabs %}

## 3. Install Cover CLI

{% tabs %}
{% tab title="Windows" %}

1. Download the Diffblue Cover CLI `.exe` installer or `.zip` file from:\
   \
   \&#xNAN;**-** The Diffblue website - [Free Trial](https://www.diffblue.com/try-cover) version.\
   \
   \&#xNAN;**-** The link sent to you via your Diffblue Cover welcome email.\
   \
   \&#xNAN;**-** Your organization's internal file/app store.\\
2. If you use the installer, run the `.exe` installer and follow the on-screen prompts - during installation you can select where to install Diffblue Cover.
3. If you use the archive file, extract the `.zip` file to an appropriate installation folder. Add the install folder path to your the `PATH` environment variable or create a new `%DCOVER%` environment variable and add that to `PATH`.
4. When your done, restart your PC. Once complete, open Windows PowerShell and enter `dcover version` to check the install and `PATH` configuration - if all is OK, Cover will display the current version.
   {% endtab %}

{% tab title="Linux/macOS" %}

1. Download the Diffblue Cover CLI `.zip` file from:\
   \
   \&#xNAN;**-** The Diffblue website - [Free Trial](https://www.diffblue.com/try-cover) version.\
   \
   \&#xNAN;**-** The link sent to you via your Diffblue Cover welcome email.\
   \
   \&#xNAN;**-** Your organization's internal file/app store.\\
2. Unzip the Cover CLI zip file to an appropriate installation location (for example, `~/bin`) and add this location in the `PATH` environment variable using the following example commands:\\

   ```
   mkdir ~/bin
   cd ~/bin
   unzip ~/diffblue-cover*.zip
   export PATH=$PATH:~/bin
   ```

   \
   **Reminder:** Make sure that the `PATH` environment variable is set permanently according to your operating system instructions.
3. Once complete, run `dcover version` to check the install and `PATH` configuration - if all is OK, Cover will display the current version.
   {% endtab %}
   {% endtabs %}

## 4. Apply licenses

{% tabs %}
{% tab title="Cover Plugin" %}
Once IntelliJ has restarted (after install), you'll be prompted for your license key (provided in your welcome email or by your organization) to activate the plugin. Diffblue Cover requires a remote license check with the Diffblue licensing server each time it's used. For help troubleshooting license keys, network connections, and proxy server settings, see [Licensing](/get-started/licensing). Note that:

* Applying a license provides access to the Teams and Enterprise Editions of Diffblue Cover.
* Cover Plugin Community Edition is free to use but does require product verification to activate your perpetual license.
* Offline license activation is available with the Diffblue Cover Enterprise Edition only. This can only be done through the CLI.
* See [Cover Editions](/updates-and-upgrades/cover-editions) and [Licensing](/get-started/licensing) for more details.

<figure><img src="/files/0SKxPD4QVPrjJQiM4rX0" alt="" width="563"><figcaption></figcaption></figure>
{% endtab %}

{% tab title="Cover CLI" %}
Diffblue Cover requires a remote license check with the Diffblue licensing server each time it's used. For help troubleshooting license keys, network connections, and proxy server settings, as well as details of offline licensing (Enterprise Edition only), see [Licensing](/get-started/licensing).

* To activate your license, open Windows PowerShell (Windows) or Terminal (macOS/Linux) and enter the command `dcover activate <license-key>` - replace `<license-key>` with the license key provided in your welcome email or provided by your organization.
* Entering multiple different license keys will overwrite the existing key.
* You can check your license status by running the command `dcover license`
  {% endtab %}
  {% endtabs %}

## 5. Try it out

Four steps to automatically write tests - clone an example project, compile the project and check your environment, learn a few basics, and then one click or one command to write tests.

### Step 1 - Clone the example project Spring PetClinic

We're going to make use of an example project (Spring PetClinic) to show the Diffblue Cover Plugin for IntelliJ at work. First, we'll clone the project from the Git repo:

{% tabs %}
{% tab title="Git CLI" %}

1. Open a command line and navigate to where you want to clone this project.
2. Run the following command:

```
git clone https://github.com/diffblue/demo-spring-petclinic
```

{% endtab %}

{% tab title="IntelliJ UI" %}
From IntelliJ select `File > New... > Project from version control`.

* Ensure `Git` is selected in `Version control`.
* Enter `https://github.com/diffblue/demo-spring-petclinic` as the URL.
* Select the directory/folder to clone the project to.
* When you're ready, click `Clone`.

<div align="left"><figure><img src="/files/i3JYCV6lbSw7AlPMCYsO" alt="" width="375"><figcaption></figcaption></figure></div>
{% endtab %}
{% endtabs %}

### Step 2 - Compile the project and check your environment

Before we write any tests, we need to compile the PetClinic project. Diffblue Cover works by analyzing the bytecode of any project used with Cover. You can do this from the Maven plugin in IntelliJ (click the `Maven` tab, open `petclinic > Lifecycle`, and double-click `package`) or open a command line, navigate to the directory containing the PetClinic project, and run the Maven `package` command:

```
cd demo-spring-petclinic
./mvnw package
```

**Basic prerequisites:**

* Java 8, 11, 17, or 21 compatible source code, or Kotlin source code.
* Maven 3.2.5+ or Gradle 4.9+ build tools.
* Any project (for use with Diffblue Cover) must compile and run with no failing unit tests. JUnit and TestNG testing frameworks are supported.

**More details:**

Diffblue Cover requires that the system environment (hardware, operating system, network connectivity, Java installation) as well as the project environment (build tooling, dependencies, presence of artifacts, existing unit tests) meet the minimum requirements as detailed in [Specs & Reqs](/get-started/specs-and-reqs). Cover will perform an environment check before analysis begins to ensure that the requirements are met - if there are any issues, these will be reported via the Diffblue Cover panel in IntelliJ using E(Environment) [Output Codes](/features/output-codes).

**Check your environment:**

Cover CLI also provides a command line option to run these checks, without writing any tests, useful when you just want to check-out your environment without doing anything else. To run a preflight environment check, open a command line, navigate to the directory containing the PetClinic project, and run the preflight checks:

```
cd demo-spring-petclinic
dcover create --preflight
```

### Step 3 - A few basics

Before we start using Diffblue Cover to write tests, it's worth covering a few basics first.

{% tabs %}
{% tab title="Cover Plugin" %}
We won't cover the whole UI here, but here are a few useful gutter icons to get you started:

<table><thead><tr><th width="94.08517077388666">Icon</th><th>Description</th></tr></thead><tbody><tr><td><img src="/files/kSq2f7FYyk4QPogn2ptc" alt=""></td><td><strong>Write tests</strong> - click this icon to write tests for this method or class.</td></tr><tr><td><img src="/files/Cdl9YnR65ZpwXpGN06xu" alt=""></td><td><strong>Not testable</strong> - this method or class can't be tested. Click the icon to find out why.</td></tr><tr><td><img src="/files/nwQxmLYTgGHJaWkv45S6" alt=""></td><td><strong>Private method</strong> - this method can't be tested as it's private, although it may be tested indirectly via a public method. If you'd like Cover to write unit tests for this method, you can either make the method public or package protected.</td></tr><tr><td><img src="/files/AF6UMYzB5WODbuBUbHQh" alt=""></td><td><strong>Test maintenance</strong> - displayed next to test classes and methods in project test files. Click the icon to update or delete tests for the method or class.</td></tr><tr><td><img src="/files/nulYfCvxl0IdIwqfy7ZN" alt=""></td><td><strong>Delete test</strong> - displayed next to your test methods in project test files. Click the icon to delete a test method.</td></tr></tbody></table>
{% endtab %}

{% tab title="Cover CLI" %}
We won't cover every CLI command option, but here are a few details to get you started:

<table><thead><tr><th width="216.74566473988432">Command</th><th>Description</th></tr></thead><tbody><tr><td><code>dcover help</code></td><td><strong>Help</strong> - get, err, help. Use this with the other commands as well to get some details of what options are available (like <code>dcover create help</code> to get details of the available optional arguments).</td></tr><tr><td><p><code>dcover activate</code></p><p><code>&#x3C;license-key></code></p></td><td><strong>Activate License</strong> - apply/activate a license. Replace <code>&#x3C;license-key></code> with the license key provided in your welcome email or provided by your organization.</td></tr><tr><td><code>dcover license</code></td><td><strong>Check License</strong> - display your current license status.</td></tr><tr><td><code>dcover version</code></td><td><strong>Check Version</strong> - display the version of Diffblue Cover CLI.</td></tr><tr><td><code>dcover create</code></td><td><strong>Create Tests</strong> - write tests for the project (run from the root directory of the project). You can restrict this further by simply specifying the method or class path - this is detailed a little further in the example in Step 4 below.</td></tr><tr><td><code>dcover create</code><br><code>--&#x3C;arguments></code></td><td><strong>Optional Arguments</strong> - there's a few, OK quite a lot. The optional arguments provide access to deeper functionality within Cover CLI such as creating coverage reports, specifying a build configuration file, and running preflight checks (this one is used in Step 3 below).</td></tr></tbody></table>
{% endtab %}
{% endtabs %}

### Step 4 - Automatically write tests for the example project

In this step we're going to use Diffblue Cover to automatically write tests for two classes and then for the entire PetClinic project. We'll make use of Cover Plugin for IntelliJ and run Cover CLI commands from a command line. You can also use Cover CLI straight from the IntelliJ terminal - handy when you’re using both tools in partnership

Note that the examples here use `DiffblueTest` as the default class name suffix and `diffbluetest` as the default method name prefix, just to highlight the tests created by Diffblue Cover.

* To change your suffix and prefix in IntelliJ, go to `Diffblue > Change Settings > Test Naming > Class Template/Method Template`.
* To change your suffix and prefix in Cover CLI, use the `--class-name-template` and `--method-name-template` command arguments - see Cover CLI [Commands & Arguments](/features/cover-cli/commands-and-arguments) for details.

***

**First we'll use Cover Plugin for IntelliJ:**

1. In IntelliJ, open the PetClinic project and navigate to a class - for example, `OwnerController`.
2. To create tests for this class, click on the <img src="/files/4lkNDIk55EL8087NS6kl" alt="" data-size="line"> `Write Tests` gutter icon next to the line `class OwnerController`.
3. Click the links in the Diffblue Cover panel to see the tests produced. And that's it, simple - 1 click, 9 methods analyzed, 7 tests written, around 340 lines of code, and all in around 65 seconds - computationally perfect, human readable. You'll find these tests in the `test` folder for the project.

```java
package org.springframework.samples.petclinic.owner;

import ...

@ContextConfiguration(classes = {OwnerController.class})
@ExtendWith(SpringExtension.class)
class OwnerControllerDiffblueTest {
	@Autowired
	private OwnerController ownerController;

	@MockBean
	private OwnerRepository ownerRepository;

	/**
	 * Method under test: {@link OwnerController#initCreationForm(Map)}
	 */
	@Test
	void diffbluetestInitCreationForm() throws Exception {
		MockHttpServletRequestBuilder requestBuilder = MockMvcRequestBuilders.get("/owners/new");
		MockMvcBuilders.standaloneSetup(ownerController)
			.build()
			.perform(requestBuilder)
			.andExpect(MockMvcResultMatchers.status().isOk())
			.andExpect(MockMvcResultMatchers.model().size(1))
			.andExpect(MockMvcResultMatchers.model().attributeExists("owner"))
			.andExpect(MockMvcResultMatchers.view().name("owners/createOrUpdateOwnerForm"))
			.andExpect(MockMvcResultMatchers.forwardedUrl("owners/createOrUpdateOwnerForm"));
	}

....
```

***

**Now we'll move on to using Cover CLI.**

1. Open a command line or open the IntelliJ terminal, and navigate to the demo-spring-petclinic folder.
2. Enter the following command to write tests for the `PetController` class:

```
dcover create org.springframework.samples.petclinic.owner.PetController
```

3. Cover CLI will now write the tests for the class - 1 command line, 10 methods analyzed, 9 tests written, around 214 lines of code created, and again, all in around 65 seconds - computationally perfect, human readable. You'll find these tests in the `test` folder for the project.

```java
package org.springframework.samples.petclinic.owner;

import ...

@ContextConfiguration(classes = {PetController.class})
@ExtendWith(SpringExtension.class)
class PetControllerDiffblueTest {
	@MockBean
	private OwnerRepository ownerRepository;

	@Autowired
	private PetController petController;

	/**
	 * Method under test: {@link PetController#populatePetTypes()}
	 */
	@Test
	void diffbluetestPopulatePetTypes() {
		ArrayList<PetType> petTypeList = new ArrayList<>();
		when(ownerRepository.findPetTypes()).thenReturn(petTypeList);
		Collection<PetType> actualPopulatePetTypesResult = petController.populatePetTypes();
		assertSame(petTypeList, actualPopulatePetTypesResult);
		assertTrue(actualPopulatePetTypesResult.isEmpty());
		verify(ownerRepository).findPetTypes();
	}
....
```

4. Once you're happy with this first set of tests, create the full test suite for the entire PetClinic project - enter `dcover create`. That's it, two "words" and you're done. Of course this one takes a **little** longer to complete (around five minutes) as it creates tests across the entire PetClinic project, analyzing 97 methods and creating 77 tests (exact count may vary slightly).

## More...

### What does Diffblue Cover do?

<div align="left"><figure><img src="/files/4VbARkXKkTu5MYjP2WsR" alt=""><figcaption></figcaption></figure></div>

* Diffblue Cover first ensures that your code is compiled and examines each method that Cover will create tests for, including any dependent methods.
* Cover then creates initial test candidates and uses reinforcement learning to evaluate and adjust the test candidate for each method. This process is repeated until the set of tests that optimize coverage are selected and committed to your code base.

### Next steps

Now you're up and running with Diffblue Cover:

* Have a scan through the [Test examples](/features/cover-plugin/writing-tests/test-examples) topic which provides some additional source code examples along with an explanation of the tests created by Diffblue Cover.
* Create some tests for your own project - as long as you have a project that compiles and your environment meets the Cover [prerequisites](/get-started/specs-and-reqs), you're literally a click away from AI written tests, created in seconds instead of hours.
* See [Cover Plugin](/features/cover-plugin) and [Cover CLI](/features/cover-cli) to familiarize yourself with the full set of features and functions.
* Cover Pipeline for GitLab is also available as a free trial version, see [Cover Pipeline for GitLab](/features/cover-pipeline/cover-pipeline-for-gitlab) for details - for all other CI integrations please [contact](https://www.diffblue.com/contact/) Diffblue.

{% hint style="info" %}
If you're only planning to use Cover Plugin Community Edition (free), you may just want to jump straight to the topic.
{% endhint %}

### Notes

> Demo code, statistics, and timings used throughout Diffblue docs and eLearning videos are based on in-house demonstrations. These may differ slightly from those experienced within a live production environment.


# Get started - Cover Plugin

Get started with Diffblue Cover Plugin for IntelliJ - in short, install the plugin, apply your license, and you're ready to go. This topic also provides an example and some next steps.

If you've already done this as part of your free trial, you may want to skip this and jump straight to the [Cover Plugin](/features/cover-plugin) details, or perhaps you want to update to the latest version - see [Update Cover](/get-started/update-cover).

## eLearning

**Short on time?** If you'd like a fast-track experience check out our getting started video. \[5 min]

{% embed url="<https://youtu.be/wQ-W8Q5FYBU?feature=shared>" %}

## 1. Install Diffblue Cover Plugin for IntelliJ

{% tabs %}
{% tab title="From IntelliJ IDE" %}

1. In the IntelliJ IDE, open the `Plugins` menu - either `File > Settings > Plugins` (Windows/Linux) or `IntelliJ IDEA > Preferences > Plugins` (macOS).
2. Select the `Marketplace` tab, search for `Diffblue`, and click `Install`. Your plugin will now be downloaded and installed.
3. When prompted, click `Restart IDE` to complete the install.

<div align="left"><figure><img src="/files/yZdmQKOSfbjavEKeQT2C" alt="" width="563"><figcaption></figcaption></figure></div>
{% endtab %}

{% tab title="From a ZIP Archive" %}

1. Download the Diffblue Cover Plugin for IntelliJ as a `.zip` bundle from:\
   \
   \&#xNAN;**-** The Diffblue website - [Free Community Edition](https://www.diffblue.com/community-edition/download) or [Free Trial](https://www.diffblue.com/try-cover) versions.\
   \
   \&#xNAN;**-** The [JetBrains Marketplace](https://plugins.jetbrains.com/) (IntelliJ Plugin Marketplace).\
   \
   \&#xNAN;**-** The link sent to you via your Diffblue Cover welcome email.\
   \
   \&#xNAN;**-** Your organization's internal file/app store.\\
2. In the IntelliJ IDE, open the `Plugins` menu - either `File > Settings > Plugins` (Windows/Linux) or `IntelliJ IDEA > Preferences > Plugins` (macOS).
3. Click on the cog icon next to the `Installed` tab and select `Install Plugin from Disk...`. Navigate to the location of the plugin, select the zip file, and click `OK`.
4. When prompted, click `Restart IDE` to complete the install.

<div align="left"><figure><img src="/files/ycvubmiRG7vxeLQ2vK8C" alt="" width="266"><figcaption></figcaption></figure></div>
{% endtab %}
{% endtabs %}

## 2. Apply a license

Once IntelliJ has restarted, you'll be prompted for your license key (provided in your welcome email or by your organization) to activate the plugin. Alternatively, the license can be activated at any time from the IntelliJ toolbar `Diffblue > Activate License`. Diffblue Cover requires a remote license check with the Diffblue licensing server each time it's used. For help troubleshooting license keys, network connections, and proxy server settings, see [Licensing](/get-started/licensing). Note that:

* Applying a license provides access to the Teams and Enterprise Editions of Diffblue Cover.
* Cover Plugin Community Edition is free to use but does require product verification to activate your perpetual license.
* Offline license activation is available with the Diffblue Cover Enterprise Edition only. This can only be done through the CLI.
* See [Cover Editions](/updates-and-upgrades/cover-editions) and [Licensing](/get-started/licensing) for more details.

<figure><img src="/files/nLbAjbZun35ubmyQlsb5" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/0SKxPD4QVPrjJQiM4rX0" alt="" width="563"><figcaption></figcaption></figure>

## 3. Try it out

Four steps to automatically write tests - clone an example project, compile the project and check your environment, learn a few basics, and then one click or one command to write tests.

### Step 1 - Clone the example project Spring PetClinic

We're going to make use of an example project (Spring PetClinic) to show the Diffblue Cover Plugin for IntelliJ at work. First, we'll clone the project from the Git repo:

{% tabs %}
{% tab title="Git CLI" %}

1. Open a command line and navigate to where you want to clone this project.
2. Run the following commands:

```
git clone https://github.com/diffblue/demo-spring-petclinic
```

3. Open the PetClinic project in IntelliJ.
   {% endtab %}

{% tab title="IntelliJ UI" %}
From IntelliJ select `File > New... > Project from version control`.

* Ensure `Git` is selected in `Version control`.
* Enter `https://github.com/diffblue/demo-spring-petclinic` as the URL.
* Select the directory/folder to clone the project to.
* When you're ready, click `Clone`.

<div align="left"><figure><img src="/files/i3JYCV6lbSw7AlPMCYsO" alt="" width="375"><figcaption></figcaption></figure></div>
{% endtab %}
{% endtabs %}

### Step 2 - Compile the project and check your environment

Before we write any tests, we need to compile the PetClinic project. Diffblue Cover works by analyzing the bytecode of any project used with Cover. You can do this from the Maven plugin in IntelliJ - click the `Maven` tab, open `petclinic > Lifecycle`, and double-click `package`.

<figure><img src="/files/CpSABdj5MxEqe7YDwlI3" alt=""><figcaption></figcaption></figure>

**Basic prerequisites:**

* Java 8, 11, 17, or 21 compatible source code, or Kotlin source code.
* Maven 3.2.5+ or Gradle 4.9+ build tools.
* The project (for use with Diffblue Cover) must compile and run with no failing unit tests.

  JUnit and TestNG testing frameworks are supported.

**More details:**

Diffblue Cover requires that the system environment (hardware, operating system, network connectivity, Java installation) as well as the project environment (build tooling, dependencies, presence of artifacts, existing unit tests) meet the minimum requirements as detailed in [Specs & Reqs](/get-started/specs-and-reqs). Cover Plugin will perform an environment check before analysis begins to ensure that the requirements are met - if there are any issues, these will be reported via the Diffblue Cover panel in IntelliJ using E (Environment) [Output Codes](/features/output-codes).

{% hint style="info" %}
Note that you can run `dcover create --preflight` (using [Diffblue Cover CLI](/get-started/get-started/get-started-cover-cli)) to check the Cover prerequisites for your project, without performing any other actions.
{% endhint %}

### Step 3 - A couple of basics

We won't cover the whole UI here, but here are a few useful gutter icons to get you started:

<table><thead><tr><th width="94.08517077388666">Icon</th><th>Description</th></tr></thead><tbody><tr><td><img src="/files/kSq2f7FYyk4QPogn2ptc" alt=""></td><td><strong>Write tests</strong> - click this icon to write tests for this method or class.</td></tr><tr><td><img src="/files/Cdl9YnR65ZpwXpGN06xu" alt=""></td><td><strong>Not testable</strong> - this method or class can't be tested. Click the icon to find out why.</td></tr><tr><td><img src="/files/nwQxmLYTgGHJaWkv45S6" alt=""></td><td><strong>Private method</strong> - this method can't be tested as it's private, although it may be tested indirectly via a public method. If you'd like Cover to write unit tests for this method, you can either make the method public or package protected.</td></tr><tr><td><img src="/files/AF6UMYzB5WODbuBUbHQh" alt=""></td><td><strong>Test maintenance</strong> - displayed next to test classes and methods in project test files. Click the icon to update or delete tests for the method or class.</td></tr><tr><td><img src="/files/nulYfCvxl0IdIwqfy7ZN" alt=""></td><td><strong>Delete test</strong> - displayed next to your test methods in project test files. Click the icon to delete a test method.</td></tr></tbody></table>

### Step 4 - Automatically write tests for the example project

1. Navigate to a class - for example, `OwnerController`.
2. To create tests for this class, click on the <img src="/files/4lkNDIk55EL8087NS6kl" alt="" data-size="line"> `Write Tests` gutter icon next to the line `class OwnerController`.
3. Click the links in the Diffblue Cover panel to see the tests produced - example below.

And that's it, simple - 1 click, 9 methods analyzed, 7 tests written, around 340 lines of code, and all in around 65 seconds - computationally perfect, human readable.

```java
package org.springframework.samples.petclinic.owner;

import ...

@ContextConfiguration(classes = {OwnerController.class})
@ExtendWith(SpringExtension.class)
class OwnerControllerDiffblueTest {
	@Autowired
	private OwnerController ownerController;

	@MockBean
	private OwnerRepository ownerRepository;

	/**
	 * Method under test: {@link OwnerController#initCreationForm(Map)}
	 */
	@Test
	void diffbluetestInitCreationForm() throws Exception {
		MockHttpServletRequestBuilder requestBuilder = MockMvcRequestBuilders.get("/owners/new");
		MockMvcBuilders.standaloneSetup(ownerController)
			.build()
			.perform(requestBuilder)
			.andExpect(MockMvcResultMatchers.status().isOk())
			.andExpect(MockMvcResultMatchers.model().size(1))
			.andExpect(MockMvcResultMatchers.model().attributeExists("owner"))
			.andExpect(MockMvcResultMatchers.view().name("owners/createOrUpdateOwnerForm"))
			.andExpect(MockMvcResultMatchers.forwardedUrl("owners/createOrUpdateOwnerForm"));
	}

....
```

Note that the examples here use `DiffblueTest` as the default class name suffix and `diffbluetest` as the default method name prefix, just to highlight the tests created by Diffblue Cover. To change your suffix and prefix in IntelliJ, go to `Diffblue > Change Settings > Test Naming > Class Template/Method Template`.

## More...

### What does the plugin do?

<div align="left"><figure><img src="/files/4VbARkXKkTu5MYjP2WsR" alt=""><figcaption></figcaption></figure></div>

* Diffblue Cover first ensures that your code is compiled and examines each method that Cover will create tests for, including any dependent methods.
* Cover then creates initial test candidates and uses reinforcement learning to evaluate and adjust the test candidate for each method. This process is repeated until the set of tests that optimize coverage are selected and committed to your code base.

### More tests

This simple "getting started" example illustrates creating tests for a class using the gutter icons (you can do the same for individual methods too). You can scale this up even further - right-click a Java source file or folder in your project structure and select **Write Tests** to create tests for all classes/methods contained within the file/folder. Of course that may not always be desirable:

* A large project with potentially a large number of tests can take some time to complete.
* License limits may apply.

<div align="left"><figure><img src="/files/sUZq0HBy8jFvLpaknLqJ" alt="" width="375"><figcaption></figcaption></figure></div>

### Next steps

Now you're up and running with Cover Plugin:

* Have a scan through the [Test examples](/features/cover-plugin/writing-tests/test-examples) topic which provides some additional source code examples along with an explanation of the tests created by Diffblue Cover.
* Create some tests for your own project - as long as you have a project that compiles and your environment meets the Cover [prerequisites](/get-started/specs-and-reqs), you're literally a click away from AI written tests, created in seconds instead of hours.
* Select your own preferences/settings for Cover Plugin - go to `Diffblue > Change Settings`.
* See [Cover Plugin](/features/cover-plugin) to familiarize yourself with the full set of plugin features and functions.

### Diffblue Cover - one AI

Diffblue Cover is also provided as a CLI tool to write tests for your entire project, all in one hit (see [Get started - Cover CLI](/get-started/get-started/get-started-cover-cli)), and can also be integrated into your CI pipeline to automatically write tests within your CI workflow (see [Get started - Cover Pipeline](/get-started/get-started/get-started-cover-pipeline)).

But Cover CLI, Cover Plugin, and Cover Pipeline are not mutually exclusive, in fact they make perfect partners. Use Cover Plugin within the IntelliJ IDE to write and check unit tests for your application during development, and also use Cover CLI directly from the IntelliJ Console or your OS command line to access the wider and deeper functionality provided by Cover CLI - finally, use Cover Pipeline within your CI tool to automate the whole process and provide consistency across your organization.

<div align="left"><figure><img src="/files/Oa3OI3sHAjBUEvcZ6ffz" alt="" width="375"><figcaption></figcaption></figure></div>


# Get started - Cover CLI

Get started with Diffblue Cover CLI - in short, install the CLI tool, apply your license, and you're ready to go. This topic also provides an example and some next steps.

If you've already done this as part of your free trial, you may want to skip this and jump straight to the [Cover CLI](/features/cover-cli) details, or perhaps you want to update to the latest version - see [Update Cover](/get-started/update-cover).

## eLearning

**Short on time?** If you'd like a fast-track experience check out our getting started video. \[6 min]

{% embed url="<https://youtu.be/eZkDQsYM9fA>" %}

## 1. Install Diffblue Cover CLI

{% tabs %}
{% tab title="Windows" %}

1. Download the latest version of Diffblue Cover CLI `.exe` installer or `.zip` file:\
   \
   \- Download directly [here using this link](https://release.diffblue.com/cli/latest)\
   \
   \- From your organization's internal file/app store.\\
2. If you use the installer, run the `.exe` installer and follow the on-screen prompts - during installation you can select where to install Diffblue Cover.
3. If you use the archive file, extract the `.zip` file to an appropriate installation folder. Add the install folder path to your `PATH` environment variable or create a new `%DCOVER%` environment variable and add that to `PATH`.
4. When you're done, restart your PC. Once complete, open Windows PowerShell and enter `dcover version` to check the install and `PATH` configuration - if all is OK, Cover will display the current version.
   {% endtab %}

{% tab title="Linux/macOS" %}

1. Download the latest version of Diffblue Cover CLI `.zip` file from:\
   \
   \- Download directly [here using this link](https://release.diffblue.com/cli/latest)\
   \
   \- From your organization's internal file/app store.\\
2. Unzip the Cover CLI zip file to an appropriate installation location (for example, `~/bin`) and add this location in the `PATH` environment variable using the following example commands:\\

   ```
   mkdir ~/bin
   cd ~/bin
   unzip ~/diffblue-cover*.zip
   export PATH=$PATH:~/bin
   ```

   \
   **Reminder:** Make sure that the `PATH` environment variable is set permanently according to your operating system instructions.
3. Once complete, run `dcover version` to check the install and `PATH` configuration - if all is OK, Cover will display the current version.
   {% endtab %}
   {% endtabs %}

## 2. Apply a license

Diffblue Cover requires a remote license check with the Diffblue licensing server each time it's used. For help troubleshooting license keys, network connections, and proxy server settings, as well as details of offline licensing (Enterprise Edition only), see [Licensing](/get-started/licensing).

* To activate your license, open Windows PowerShell (Windows) or Terminal (macOS/Linux) and enter the command `dcover activate <license-key>` - replace `<license-key>` with the license key provided in your welcome email or provided by your organization.
* Entering multiple different license keys will overwrite the existing key.
* You can check your license status by running the command `dcover license`

## 3. Try it out

Four steps to automatically write tests - check out a few basics, clone an example project, compile the project and check your environment, and finally, one command to write tests - done.

### Step 1 - A few basics

We won't cover every CLI command option, but here are a few details to get you started:

<table><thead><tr><th width="210.49071125607543">Command</th><th>Description</th></tr></thead><tbody><tr><td><code>dcover help</code></td><td><strong>Help</strong> - get, err, help. Use this with the other commands as well to get some details of what options are available (like <code>dcover help create</code> to get details of the available optional arguments).</td></tr><tr><td><code>dcover activate</code><br><code>&#x3C;license-key></code></td><td><strong>Activate License</strong> - apply/activate a license. Replace <code>&#x3C;lic-key></code> with the license key provided in your welcome email or provided by your organization.</td></tr><tr><td><code>dcover license</code></td><td><strong>Check License</strong> - display your current license status.</td></tr><tr><td><code>dcover version</code></td><td><strong>Check Version</strong> - display the version of Diffblue Cover CLI.</td></tr><tr><td><code>dcover create</code></td><td><strong>Create Tests</strong> - write tests for the project (run from the root directory of the project). You can restrict this further by simply specifying the method or class path - this is detailed a little further in the example in Step 4 below.</td></tr><tr><td><code>dcover create</code><br><code>--&#x3C;arguments></code></td><td><strong>Optional Arguments</strong> - there's a few, OK quite a lot. The optional arguments provide access to deeper functionality within Cover CLI such as creating coverage reports, specifying a build configuration file, and running preflight checks (this one is used in Step 3 below).</td></tr></tbody></table>

### Step 2 - Clone the example project Spring PetClinic

We're going to make use of an example project (Spring PetClinic) to show Diffblue Cover CLI at work. First, we'll clone the project from the Git repo:

{% tabs %}
{% tab title="IntelliJ UI" %}
From IntelliJ select `File > New... > Project from version control`.

* Ensure `Git` is selected in `Version control`.
* Enter `https://github.com/diffblue/demo-spring-petclinic` as the URL.
* Select the directory/folder to clone the project to.
* When you're ready, click `Clone`.

<div align="left"><figure><img src="/files/i3JYCV6lbSw7AlPMCYsO" alt="" width="375"><figcaption></figcaption></figure></div>
{% endtab %}

{% tab title="Git CLI" %}

1. Open a command line and navigate to where you want to clone this project.
2. Run the following command:

```git
git clone https://github.com/diffblue/demo-spring-petclinic
```

{% endtab %}
{% endtabs %}

### Step 3 - Compile the project and check your environment

Before we write any tests, we need to compile the PetClinic project. Diffblue Cover works by analyzing the bytecode of any project used with Cover. Open a command line, navigate to the directory containing the PetClinic project, and run the Maven `install` command:

```
cd demo-spring-petclinic
./mvnw install
```

**Basic prerequisites:**

* Java 8, 11, 17, or 21 compatible source code, or Kotlin source code.
* Maven 3.2.5+ or Gradle 4.9+ build tools.
* The project (for use with Diffblue Cover) must compile and run with no failing unit tests.

  JUnit and TestNG testing frameworks are supported.
* For the best results, your project needs to be completely built from the root.

**More details:**

Diffblue Cover requires that the system environment (hardware, operating system, network connectivity, Java installation) as well as the project environment (build tooling, dependencies, presence of artifacts, existing unit tests) meet the minimum requirements as detailed in [Specs & Reqs](/get-started/specs-and-reqs). Cover CLI will perform an environment check before analysis begins to ensure that the requirements are met - if there are any issues, these will be reported via the Diffblue Cover panel in IntelliJ using E(Environment) [Output Codes](/features/output-codes).

Further details can be found in the [Compiling your project successfully](/features/cover-cli/project-configuration/compiling-your-project) section.

**Check your environment:**

Cover CLI also provides a command line option to run these checks, without writing any tests, useful when you just want to check-out your environment without doing anything else. To run a preflight environment check, open a command line, navigate to the directory containing the PetClinic project, and run the preflight checks:

```
cd demo-spring-petclinic
dcover create --preflight
```

### Step 4 - Automatically write tests for the example project

Initially, we'll create tests for the `OwnerController` class:

```
dcover create org.springframework.samples.petclinic.owner.OwnerController
```

And that's it, simple - 1 command line, 9 methods analyzed, 14 tests written, around 340 lines of code created, and all in around 65 seconds - computationally perfect, human readable. You'll find these tests in:

`demo-spring-petclinic/src/test/java/org/springframework/`\
`samples/petclinic/owner/OwnerControllerDiffblueTest.java`

```java
package org.springframework.samples.petclinic.owner;

import ...

@ContextConfiguration(classes = {OwnerController.class})
@ExtendWith(SpringExtension.class)
class OwnerControllerDiffblueTest {
	@Autowired
	private OwnerController ownerController;

	@MockBean
	private OwnerRepository ownerRepository;

	/**
	 * Method under test: {@link OwnerController#initCreationForm(Map)}
	 */
	@Test
	void diffbluetestInitCreationForm() throws Exception {
		MockHttpServletRequestBuilder requestBuilder = MockMvcRequestBuilders.get("/owners/new");
		MockMvcBuilders.standaloneSetup(ownerController)
			.build()
			.perform(requestBuilder)
			.andExpect(MockMvcResultMatchers.status().isOk())
			.andExpect(MockMvcResultMatchers.model().size(1))
			.andExpect(MockMvcResultMatchers.model().attributeExists("owner"))
			.andExpect(MockMvcResultMatchers.view().name("owners/createOrUpdateOwnerForm"))
			.andExpect(MockMvcResultMatchers.forwardedUrl("owners/createOrUpdateOwnerForm"));
	}

....
```

Once you're happy with this first set of tests, create the full test suite for the entire PetClinic project:

```
dcover create
```

That's it, two "words" and you're done. Of course this one takes a **little** longer to complete (approx. 5 minutes) as it creates tests across the entire PetClinic project, analyzing 97 methods and creating 77 tests (exact count may vary slightly). To take a look at the tests, open a `xxxDiffblueTest.java` file in your IDE of choice (these files are saved to the `/src/test/java` directory structure by default).

Note that the examples here use `DiffblueTest` as the default class name suffix and `diffbluetest` as the default method name prefix, just to highlight the tests created by Diffblue Cover. To change your suffix and prefix, use the `--class-name-template` and `--method-name-template` command arguments - see Cover CLI [Commands & Arguments](/features/cover-cli/commands-and-arguments) for details.

## More...

### What does Cover CLI do?

<div align="left"><figure><img src="/files/4VbARkXKkTu5MYjP2WsR" alt=""><figcaption></figcaption></figure></div>

* Diffblue Cover first ensures that your code is compiled and examines each method that Cover will create tests for, including any dependent methods.
* Cover then creates initial test candidates and uses reinforcement learning to evaluate and adjust the test candidate for each method. This process is repeated until the set of tests that optimize coverage are selected and committed to your code base.

### Next steps

Now you're up and running with Cover CLI:

* Have a scan through the [Test examples](/features/cover-plugin/writing-tests/test-examples) topic which provides some additional source code examples along with an explanation of the tests created by Diffblue Cover.
* Create some tests for your own project - as long as you have a project that compiles and your environment meets the Cover [prerequisites](/get-started/specs-and-reqs), you're literally a single command line away from AI written tests, created in seconds instead of hours.
* See [Cover CLI](/features/cover-cli) to familiarize yourself with the full set of CLI features and functions.

### Diffblue Cover - one AI

Diffblue Cover is also provided as an IDE plugin tool so you can write tests with one click in the IntelliJ IDE (see [Get started - Cover Plugin](/get-started/get-started/get-started-cover-plugin)), and can also be integrated into your CI pipeline to automatically write tests within your CI workflow (see [Get started - Cover Pipeline](/get-started/get-started/get-started-cover-pipeline)).

But Cover CLI, Cover Plugin, and Cover Pipeline are not mutually exclusive, in fact they make perfect partners. Use Cover Plugin within the IntelliJ IDE to write and check unit tests for your application during development, and also use Cover CLI directly from the IntelliJ Console or your OS command line to access the wider and deeper functionality provided by Cover CLI - finally, use Cover Pipeline within your CI tool to automate the whole process and provide consistency across your organization.

<div align="left"><figure><img src="/files/Oa3OI3sHAjBUEvcZ6ffz" alt="" width="375"><figcaption></figcaption></figure></div>


# Get started - Cover Pipeline

This topic details how to use Diffblue Cover to write tests for your project as part of a CI pipeline. It outlines the basic commands that you will need to add to your CI scripts, and provides general information to understand the key steps - for specific CI tools, refer to the following:

* [Cover Pipeline for GitLab](/features/cover-pipeline/cover-pipeline-for-gitlab)
* [Cover Pipeline for GitHub](/features/cover-pipeline/cover-pipeline-for-github)
* [Quick Start - Jenkins](/features/cover-pipeline/cover-pipeline-for-ci/quick-start-jenkins)
* [Quick Start - Azure Pipelines](/features/cover-pipeline/cover-pipeline-for-ci/quick-start-guide-azure)
* [Quick Start - AWS Codebuild](/features/cover-pipeline/cover-pipeline-for-ci/quick-start-guide-aws)

## Assumptions

This topic assumes that you have:

* A basic understanding of Cover CLI - see [Get started - Cover CLI](/get-started/get-started/get-started-cover-cli).
* A Maven or Gradle project that:
  * Compiles.
  * Does not have non-compiling or failing tests.
  * Is stored in a Git repository with a CI tool enabled.
* A basic understanding of your chosen CI tool.
* The ability to store secrets variables for your CI tool.
* Diffblue Cover CLI release zip stored in the cloud, along with an appropriate license key.

## Summary

To integrate Diffblue Cover into your CI pipeline, we will guide you through creating a CI script that:

1. [Builds your project.](#1.-building-the-project)
2. [Downloads and activates Diffblue Cover CLI.](#2.-downloading-and-activating-diffblue-cover-cli)
3. [Runs Diffblue Cover to create tests.](#3.-running-diffblue-cover-cli-to-create-tests)
4. [Commits the created tests to a branch.](#4.-committing-the-created-tests-to-a-branch)

## 1. Building the project

To run Diffblue Cover CLI your project must be built. Running the project’s tests is not required, and you will save time by skipping them, but they do need to compile and pass. For example, you can use the following command to build a Maven project while skipping the tests:

```bash
mvn --batch-mode --no-transfer-progress clean install -DskipTests
```

## 2. Downloading and activating Diffblue Cover CLI

You need to give the CI run access to the Diffblue Cover files and activate the `dcover` license in order to write tests.

This step assumes that you have a URL with the Diffblue Cover CLI release zip and the license key for online activation during the CI run. If your license allows it you may wish to install Diffblue Cover with offline activation. See [Licensing](/get-started/licensing).

You will need to add two secret variables which, here, will be represented as environment variables:

* The first secret variable with the name `DIFFBLUE_COVER_URL` and the value set to the URL of the Diffblue Cover CLI release zip file.
* The second with the name `DIFFBLUE_COVER_LICENSE_KEY` and the value set to your Diffblue Cover license key.

Append the code for getting, unzipping, and activating `dcover`, to your script.

```bash
  mkdir -p "~/dcover"
  cd "~/dcover"
  curl --silent --show-error --location --output "diffblue-cover-cli.zip" "$DIFFBLUE_COVER_URL"
  unzip -q "diffblue-cover-cli.zip"
  rm -f "diffblue-cover-cli.zip"
  PATH=$PATH:~/dcover/
  dcover activate "$DIFFBLUE_COVER_LICENSE_KEY"
```

This will put the Diffblue Cover files into the `dcover` directory in the root of the workspace. The files contain a script called `dcover` which has the relative path `dcover/dcover` (or `dcover\dcover.bat` in Windows environments). The script is added to your `PATH` variable so that you can invoke Diffblue Cover CLI as `dcover` (or `dcover.bat`).

Push the changes so that your CI is triggered - ensure that you can see the successful activation of `dcover` in your CI output before moving on. You will see a line starting with "Successfully activated key" if this was successful. If Diffblue Cover did not successfully activate, please see [Licensing](/get-started/licensing) or contact [Diffblue Support](https://www.diffblue.com/support).

## 3. Running Diffblue Cover CLI to create tests

Now that Diffblue Cover is running in CI, you can use it to write tests. The next two items show how to write tests for a single module, and then how to extend this to all modules.

**Creating tests for a single module:**

Choose a module to test in your project. Append the following to your workflow file, changing `moduleToTest` to a module in your project or, if your project does not have modules, `--working-directory moduleToTest` can be removed or changed to `--working-directory`. Note that the `--batch` option makes the output more suitable for CI, as it ensures the CI logs are not cluttered with progress bar output.

```bash
  dcover create --working-directory="moduleToTest" --batch
```

Push the changes so that `dcover` runs in the CI. Once successfully complete, you should expect to see output that looks like this:

```sh
INFO  Found 7 callable methods in 2 classes
INFO
INFO  Creating tests:
INFO  ---------------
...
INFO  All 5 created tests were successfully validated.
```

If you don't see this output, the `dcover` command may need a small modification for your project, or dependencies adding, until it works. The output gives you warnings along the way to guide you. See [Commands & Arguments](/features/cover-cli/commands-and-arguments) for more information.

Depending on the size of your module/project, creating tests could take a while. You may wish to restrict test creation to a single class by specifying its fully qualified name:

```bash
  dcover create com.somepackage.SomeClass --working-directory="moduleToTest" --batch
```

**Creating tests for all modules:**

To write tests for all the modules, you can use a loop as follows:

```bash
  for MODULE in module_name_1 module_name_2 module_name_3
  do
    dcover create --batch --working-directory="$MODULE"
  done
```

## 4. Committing the created tests to a branch

To see the new tests created in the previous step in your project, you need to commit them and push back to the repository. Depending on your CI tool you may also need to configure a Git user to create the commit. We recommend creating a service account for this.

```bash
  git config user.name db-ci-bot
  git config user.email db-ci-bot@yourorg.com
```

To commit the tests, append the following to your script. This will check for any changes to Diffblue tests, add them to a commit and push to your branch.

```bash
  if [ -n "$(git status --short **/*DiffblueTest.java)" ]; then 
    git add **/*DiffblueTest.java
    git commit --message "Update Unit Tests for $(git rev-parse --short HEAD)"
    git push --set-upstream origin
  else
    echo "Nothing to commit"
  fi
```

**Note:** Be careful not to create an infinite CI loop here. We recommend checking the author of each commit to ensure you're not creating tests for a commit authored by your Diffblue service account.

```bash
LAST_NON_BOT_COMMIT="$(git rev-list -1 --author='^(?!db-ci-bot).*$' --perl-regexp HEAD --no-merges)"
LAST_COMMIT="$(git rev-list HEAD -1 --no-merges)"
if [[ "$LAST_NON_BOT_COMMIT" == "$LAST_COMMIT" ]]
then
  ...
fi
```

## Next steps

In this topic we've outlined the basic commands that you will need to add to your CI scripts, but we've only provided general information to understand the key steps - for specific CI tools, refer to the following:

* [Cover Pipeline for GitLab](/features/cover-pipeline/cover-pipeline-for-gitlab)
* [Cover Pipeline for GitHub](/features/cover-pipeline/cover-pipeline-for-github)
* [Quick Start - Jenkins](/features/cover-pipeline/cover-pipeline-for-ci/quick-start-jenkins)
* [Quick Start - Azure Pipelines](/features/cover-pipeline/cover-pipeline-for-ci/quick-start-guide-azure)
* [Quick Start - AWS Codebuild](/features/cover-pipeline/cover-pipeline-for-ci/quick-start-guide-aws)

## Diffblue Cover - one AI

Diffblue Cover is also provided as an IDE plugin tool so you can write tests with one click in the IntelliJ IDE (see [Get started - Cover Plugin](/get-started/get-started/get-started-cover-plugin)) and as a developer CLI tool to write tests for your entire project, all in one hit (see [Get started - Cover CLI](/get-started/get-started/get-started-cover-cli)).

But Cover CLI, Cover Plugin, and Cover Pipeline are not mutually exclusive, in fact they make perfect partners. Use Cover Plugin within the IntelliJ IDE to write and check unit tests for your application during development, and also use Cover CLI directly from the IntelliJ Console or your OS command line to access the wider and deeper functionality provided by Cover CLI - finally, use Cover Pipeline within your CI tool to automate the whole process and provide consistency across your organization.

<div align="left"><figure><img src="/files/Oa3OI3sHAjBUEvcZ6ffz" alt="" width="375"><figcaption></figcaption></figure></div>


# Get started - Cover Reports

Get started with Diffblue Cover Reports - in short, check the prerequisites, download and install Cover Reports, create and upload a reports bundle, and finally, visualize your coverage data.

Cover Reports is a server-side tool accessed via a web browser - Chrome, Edge, Safari, or Firefox. Cover CLI and/or Cover Pipeline are used to create and upload coverage data - Cover Reports is used to visualize that data. This getting started topic focuses on Cover CLI - for information on using Cover Reports with Cover Pipeline see [Cover Pipeline](/features/cover-pipeline).

{% hint style="info" %}
This topic covers Docker install only. As an alternative, Cover Reports can be installed from a zip archive or exe installer. These provide for running Cover Reports as a Windows Service, Linux Service, Windows .bat, or macOS/Linux .sh, and removes the need to use Docker. These also provide various database configuration options to provide further flexibility. See [Install and update Cover Reports](/features/cover-reports/cover-reports-administrator/installation) for details.
{% endhint %}

## eLearning

Prefer video? No problem. Check out our overview video.

{% embed url="<https://youtu.be/vr217Qockfo>" %}

## 1. Check the prerequisites

A summary of Cover Reports prerequisites are listed below - see [Specs & Reqs](/get-started/specs-and-reqs) for full details.

**Client workstation - Cover Reports Contributor:**

* Diffblue Cover CLI
* JaCoCo 0.8.3+
* Network connectivity between the user's workstation and the Cover Reports server.

**Client workstation - Cover Reports User:**

* The latest version of Chrome, Edge, Safari, or Firefox with a screen resolution of 1920 x 1080 or higher.
* Network connectivity between the user's workstation and the Cover Reports server.

**Server hosting Cover Reports - Cover Reports Administrator::**

* Docker Engine 20.10.17
* 4GB RAM (8GB recommended), 2GB\* minimum available disk space, 4 CPU cores.
* 2GB Java heap allocation, 4GB recommended.
* Docker Compose v2.10.2
* Network connectivity between the server and client workstations.
* Internet connection if using Docker Hub for install.

## 2. Install Diffblue Cover Reports

{% tabs %}
{% tab title="Docker Archive" %}

1. Using the link provided by Diffblue, download the Cover Reports `.tar.gz` file (e.g. `diffblue-cover-reports-2023.07.02.tar.gz`) to the server you plan to use to host Cover Reports. Contact [Diffblue Support](https://www.diffblue.com/support) if you don't have the download link.
2. From the directory containing the Cover Reports `.tar.gz` file, load the Docker bundle:

```
docker load -i /path/diffblue-cover-reports-<version>.tar.gz
```

3. In your shell, navigate to your preferred install directory (we'll now refer to this as `$COVER_REPORTS_HOME`). Using the link provided by Diffblue, download the Cover Reports Docker Compose file `docker-compose.yml` to `$COVER_REPORTS_HOME`. Contact [Diffblue Support](https://www.diffblue.com/support) if you don't have the download link.
4. From the `$COVER_REPORTS_HOME` directory, start Cover Reports:

```
docker compose up -d
```

5. Finally, open a browser on a client PC that has access to the Cover Reports server and navigate to the Cover Reports Home Page (`<HOSTURL>:8080`).

<div align="center"><figure><img src="/files/KreeW9CtdUA3oaxbmhfn" alt=""><figcaption></figcaption></figure></div>
{% endtab %}

{% tab title="Docker Hub" %}

1. To access the repository please [sign up to Docker Hub](https://hub.docker.com/) and provide [Diffblue Support](https://www.diffblue.com/support) with your username. Diffblue Support will grant access according to your subscription terms.
2. In your shell (from the server you plan to use to host Cover Reports), log in to Docker Hub using the `docker login` command with either your username and password or username and [Docker Hub Access Token](https://docs.docker.com/docker-hub/access-tokens), for example:

```
docker login -u <username> <password_or_token>
```

3. In your shell, navigate to your preferred install directory (we'll now refer to this as `$COVER_REPORTS_HOME`). Using the link provided by Diffblue, download the Cover Reports Docker Compose file `docker-compose.yml` to `$COVER_REPORTS_HOME`. Contact [Diffblue Support](https://www.diffblue.com/support) if you don't have the download link.
4. From the `$COVER_REPORTS_HOME` directory, start Cover Reports:

```
docker compose up -d
```

5. Finally, open your browser and navigate to the Cover Reports Home Page (`<HOSTURL>:8080`).

<div align="center"><figure><img src="/files/KreeW9CtdUA3oaxbmhfn" alt=""><figcaption></figcaption></figure></div>
{% endtab %}
{% endtabs %}

## 3. Create and upload a reports bundle

Use Cover CLI to create a coverage data file for your project - this is referred to as a "reports bundle". You can do this on your own project, or you can use the example PetClinic Spring project that's used as part of the [Get started - Cover CLI](/get-started/get-started/get-started-cover-cli) topic.

Note that, to save you a little time, there's a demo project provided as part of Cover Reports so you can click `Open Demo Project` from the Reports splash screen and skip this Cover CLI step. If you or your organization have already used Cover Reports, this option won't be available.

```
cd demo-spring-petclinic
dcover create --coverage-reports
    --upload=http://my-cover-reports-service:8080
```

The optional arguments used with `dcover create` perform the following:

* `--coverage-reports` is used create the coverage data files using Cover and JaCoCo.
* `--upload` is used to define the URL to upload the reports bundle to - i.e. the URL for your Cover Reports server install. Note that HTTPS direct is currently not supported.

## 4. Visualize your data

Now the fun bit - taking a look at your coverage data. Please see [Cover Reports User](/features/cover-reports/cover-reports-user) for a detailed guide through the visualisation dashboard.

## Next steps

Now you're up and running with Cover Reports, use Cover CLI to create reports bundles for your own projects and start to build your data sets over time. In general, Cover Reports is pretty straightforward to use, especially from a UI perspective, but check out the [Cover Reports](/features/cover-reports) topic for more details on using Cover Reports.


# Specs & Reqs

Environment prerequisites, plus system specifications and requirements

## Prerequisites

Diffblue Cover requires that the system environment (hardware, operating system, network connectivity, Java installation) as well as the project environment (build tooling, dependencies, presence of artifacts, existing unit tests) meet the minimum requirements as outlined below. Diffblue Cover will perform an environment check before analysis begins to ensure that the requirements are met.

{% hint style="info" %}
Cover CLI provides a `--preflight` option (see [Preflight checks](/features/cover-cli/project-configuration/preflight)) which can be used to check the status of the prerequisites without performing the project analysis. This option can also be run without a license key.
{% endhint %}

### Cover Plugin & Cover CLI

* 32 GB RAM, 5 GB minimum available disk space, 4 CPU cores
* 8GB Java heap allocated
* TCP connection **\***
* Windows 11 Pro, Windows 10 Enterprise, Ubuntu 18.04, RHEL 7.7, macOS 10.15
* Java 8 (8u351+), Java 11 (11.0.17+), Java 17 (17.0.5+), Java 21 (21.0.1+) or Java 25. Note only 64-bit versions of Java are supported.
* For Maven projects: Maven version 3.2.5+
* For Gradle projects: Gradle version 4.9+ (must be [compatible with your version of Java](https://docs.gradle.org/current/userguide/compatibility.html)).
* For Ant projects: Ant version 1.10.4+
* Android projects are not supported.
* JUnit 4.11 - 4.13, JUnit 5.0 - 5.12.2, or TestNG 6.0.1 - 7.10.2.
* For Java 8 projects: Mockito 1.9.5 - 4.11.0
* For Java 11 projects: Mockito 2.22.0 - 5.21.0
* For Java 17 projects: Mockito 4.1.0 - 5.21.0
* For Java 21 projects: Mockito 4.1.0 - 5.21.0
* For Java 25 projects: Mockito 5.21.0+
* For Kotlin projects: one of the above versions of Java and associated Mockito
* All necessary tooling to build the project
* The project must compile and run with no failing unit tests
* Access to a dependency repository to download transient dependencies
* Access to the Diffblue licensing server for remote license check

**\*** Cover requires the use of an analysis service that communicates with Cover Plugin and Cover CLI via TCP connections on localhost. In particular, Cover must be able to start up the analysis service and open a bi-directional TCP connection between the frontend and the service.

### Cover Plugin

* IntelliJ IDEA version 2025.3 or later
* A minimum of 4GB memory allocated to IntelliJ

### Cover Pipeline for GitLab

* GitLab subscription - Free, Premium, or Ultimate Edition.

### Cover Reports

**Server hosting Cover Reports - Cover Reports Administrator:**

* 4GB RAM (8GB recommended), 2GB\* minimum available disk space, 4 CPU cores.
* 2GB Java heap allocation, 4GB recommended.
* Docker Install - Docker Engine 20.10.17, Docker Compose v2.10.2, and if you're using Docker Hub you'll also need an internet connection.
* Zip Install & Windows Installer - Java JDK 17+ (and available in your PATH system environment variable). For production use, you'll also need to provide a vanilla PostgreSQL 14 database (see Cover Reports > [Configuration options](/features/cover-reports/cover-reports-administrator/configuration-options)).
* Windows Install - Windows Server 2019 and above, Windows 10 and above.
* All - Network connectivity between the server(s) and client workstations. Note that if the Cover Reports server and database server are on different hosts, good network connectivity between them will ensure good performance.

\* Note that the database server will store the data uploaded to Cover Reports. Sufficient storage should be ensured for projected usage.

**Client workstation - Cover Reports Contributor:**

* Diffblue Cover CLI
* Java 8 and 11 Projects: JaCoCo 0.8.3+
* Java 17 Projects: JaCoCo 0.8.7+
* Java 21 Projects: JaCoCo 0.8.11+
* Java 25 Projects: JacoCo 0.8.14+
* Network connectivity between the user's workstation and the Cover Reports server.

**Client workstation - Cover Reports User:**

* The latest version of Chrome, Edge, Safari, or Firefox with a screen resolution of 1920 x 1080 or higher.
* Network connectivity between the user's workstation and the Cover Reports server.

### Cover Refactor

OpenRewrite Maven or Gradle plugin (and its transitive dependencies) must be available in your local Maven or Gradle mirror.

* OpenRewrite Gradle plugin: 6.12.0
* OpenRewrite Maven plugin: 5.28.0

### Spring

Spring and Spring Boot versions are required to be compatible with your version of Java, as well as each other. Diffblue Cover supports the following:

* Java 8 Projects: Spring Boot 1.3.3 to 2.7.x, Spring Core 4.1.1 to 5.3.x
* Java 11 Projects: Spring Boot 2.1.0 to 2.7.x, Spring Core 5.1.0 to 5.3.x
* Java 17 Projects: Spring Boot 2.4.0 to 3.1.x, Spring Core 5.3.1 to 7.0.x
* Java 21 Projects: Spring Boot 2.4.0 to 4.0.x, Spring Core 5.3.26 to 7.0.x
* Java 25 Projects: Spring Boot 3.2.4 to 4.0.x, Spring Core 6.2.0 to 7.0.x
* Kotlin Projects: any of the above combinations to support the Java tests

### Dependencies

Dependencies required for running tests should be in the project configuration. Additional libraries may also be necessary depending on the project under test.

<table data-full-width="false"><thead><tr><th width="310">Dependency</th><th width="246.33333333333331">When</th><th>Version</th></tr></thead><tbody><tr><td>Surefire Plugin (<code>org.apache.maven.plugins:maven-surefire-plugin</code>)</td><td>When using Maven and junit-jupiter-engine</td><td>3.0.0-M7</td></tr><tr><td>JUnit (<code>junit:junit</code> or <code>org.junit.jupiter:junit-jupiter-engine</code>)</td><td>Unless using TestNG, Spring, or Spring Boot</td><td>4.11+</td></tr><tr><td>JUnit Launcher ( <code>org.junit.platform:junit-platform-launcher</code>)</td><td>When using junit-jupiter-engine, unless using Maven, Spring or Spring Boot</td><td>1+</td></tr><tr><td>TestNG (<code>org.testng:testng</code>)</td><td>Unless using JUnit, Spring, or Spring Boot</td><td>6 or 7</td></tr><tr><td>Spring Boot Test ( <code>org.springframework:spring-boot-test</code>)</td><td>When using Spring Boot ( <code>org.springframework:spring-boot</code>)</td><td>2+, matching version</td></tr><tr><td>Spring Boot Starter Test ( <code>org.springframework.boot:spring-boot-starter-test</code>)</td><td>When using Spring Boot ( <code>org.springframework:spring-boot</code>) for Spring WebFlux projects</td><td>2+, matching version</td></tr><tr><td>Spring Test (<code>org.springframework:spring-test</code>)</td><td>When using Spring ( <code>org.springframework:spring-core</code>) unless using Spring Boot</td><td>4.1.1+, matching version</td></tr><tr><td>Spring Boot Test Autoconfigure ( <code>org.springframework.boot:spring-boot-test-autoconfigure</code>)</td><td>When using Spring ( <code>org.springframework:spring-core</code>) for Spring WebFlux projects unless using Spring Boot</td><td>2+, matching version</td></tr><tr><td>Mockito (<code>org.mockito:mockito-core</code>)</td><td></td><td><p>5.21.0+ for Java 25</p><p>4.1.0+ for Java 21</p><p>4.1.0+ for Java 17</p><p>2.22.0+ for Java 11</p><p>1.9.5+ for Java 8</p></td></tr></tbody></table>

Other dependencies listed below may be needed, if they are transitive dependencies of your project. If one of these dependencies is required but missing, tests will be generated for some classes but not others. A message will appear in the console output indicating a missing dependency.

<table><thead><tr><th width="511">Dependency</th><th>Version</th></tr></thead><tbody><tr><td>Java Servlet API ( <code>javax.servlet:javax.servlet-api</code> or <code>jakarta.servlet:jakarta.servlet-api</code>)</td><td>4+, matching version</td></tr><tr><td>JSR107 API and SPI (<code>javax.cache:cache-api</code>)</td><td>0.2+, matching version</td></tr><tr><td>Spring Boot Starter Test ( <code>org.springframework.boot:spring-boot-starter-test</code>)</td><td>2+, matching version</td></tr><tr><td>Spring Security Config ( <code>org.springframework.security:spring-security-config</code>)</td><td>4.2.1+, matching version</td></tr><tr><td>Spring Web MVC ( <code>org.springframework:spring-webmvc</code>)</td><td>5+, matching version</td></tr><tr><td>Reactor Test ( <code>io.projectreactor:reactor-test</code>)</td><td>3.1+</td></tr></tbody></table>

### Spring projects and Hamcrest

Either:

* Use the `spring-boot-starter-test` dependency to add Hamcrest.
* Add `org.hamcrest:hamcrest`. The version of Hamcrest needs to match the relevant version of `spring-boot-test`. For example, if the user has `spring-boot-test:2.4.6`, they should look at the dependency list: [Maven Repository: org.springframework.boot spring-boot-starter-test 2.4.6](https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-test/2.4.6). This shows that the matching version is Hamcrest 2.2 (you may have to scroll).

### Spring WebFlux projects and Spring Security

When Spring Security is configured for a project in order to unlock full test generation capabilities for Spring WebFlux controllers write a custom configuration to deactivate CSRF(Cross-Site Request Forgery) security for unit tests, which can later be imported in the base class for your test:

```java
@Configuration
@EnableWebFluxSecurity
public class WebFluxTestConfig {
@Bean
public SecurityWebFilterChain filterChain(ServerHttpSecurity http) {
    return http.csrf().disable().build();
  }
}
```

***

## System Specifications & Requirements

### Supported Operating Systems

<table><thead><tr><th width="376.3333333333333">OS</th><th width="187" align="center">Cover CLI</th><th align="center">Cover Plugin</th></tr></thead><tbody><tr><td>Windows 11 Pro</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Windows 10 Enterprise</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Ubuntu 18.04</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>RHEL 7.7</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>macOS 10.15</td><td align="center">✅</td><td align="center">✅</td></tr></tbody></table>

### Supported IntelliJ Versions

From Cover Plugin version 2026.05.01 onwards, the plugin supports IntelliJ IDEA 2025.3 and all later versions, including future releases. The table below also lists the last Cover Plugin version to support each older, now-unsupported IntelliJ version.

<table><thead><tr><th width="323.59765625">IntelliJ</th><th width="139.5078125" align="center">Cover Plugin</th><th>Last Supported Cover Version</th></tr></thead><tbody><tr><td>IntelliJ 2025.3 and later</td><td align="center">✅</td><td>latest</td></tr><tr><td>IntelliJ 2025.2 (Community + Ultimate)</td><td align="center">✅</td><td>2026.02.02</td></tr><tr><td>IntelliJ 2025.1 (Community + Ultimate)</td><td align="center">✅</td><td>2025.12.01</td></tr><tr><td>IntelliJ 2024.3 (Community + Ultimate)</td><td align="center">✅</td><td>2025.07.02</td></tr><tr><td>IntelliJ 2024.2 (Community + Ultimate)</td><td align="center">✅</td><td>2025.05.01</td></tr><tr><td>IntelliJ 2024.1 (Community + Ultimate)</td><td align="center">✅</td><td>2024.11.02</td></tr><tr><td>IntelliJ 2023.3 (Community + Ultimate)</td><td align="center">✅</td><td>2024.08.01</td></tr><tr><td>IntelliJ 2023.2 (Community + Ultimate)</td><td align="center">✅</td><td>2024.04.02</td></tr><tr><td>IntelliJ 2023.1 (Community + Ultimate)</td><td align="center">✅</td><td>2023.12.02</td></tr><tr><td>IntelliJ 2022.3 (Community + Ultimate)</td><td align="center">✅</td><td>2023.07.03</td></tr><tr><td>IntelliJ 2022.2 (Community + Ultimate)</td><td align="center">✅</td><td>2023.03.02</td></tr></tbody></table>

### Supported Java Versions

<table><thead><tr><th width="380.3333333333333">Java Version</th><th width="184" align="center">Cover CLI</th><th align="center">Cover Plugin</th></tr></thead><tbody><tr><td>Open JDK</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Oracle JDK 8 (version 161+)</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Java 8 (8u351+)</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Java 11 (11.0.17+ - note that Java 11.0.7 is specifically NOT supported)</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Java 17 (17.0.5+)</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Java 21 (21.0.1+)</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Java 25</td><td align="center">✅</td><td align="center">✅</td></tr></tbody></table>

Note that only 64 bit versions of Java are supported.

### Supported Jakarta EE Versions

<table><thead><tr><th width="377.3333333333333">Jakarta</th><th width="189" align="center">Cover CLI</th><th align="center">Cover Plugin</th></tr></thead><tbody><tr><td>Java EE 8/Jakarta EE 8 Dependency Injection <strong>*</strong></td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Jakarta EE 9 Dependency Injection <strong>*</strong></td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Jakarta EE 10 Dependency Injection <strong>*</strong></td><td align="center">✅</td><td align="center">✅</td></tr></tbody></table>

**\*** Note that Diffblue Cover does not use Jakarta EE application context for tests, all injected dependencies will be mocked.

### Supported Spring Versions

<table><thead><tr><th width="381.3333333333333">Spring *</th><th width="191" align="center">Cover CLI</th><th align="center">Cover Plugin</th></tr></thead><tbody><tr><td>Java 8 Projects: Spring Boot 1.3.3 to 2.7.x, Spring Core 4.1.1 to 5.3.x, Spring WebFlux 5.0.0 to 5.3.x, Spring Boot Starter WebFlux 2.0.0 to 2.7.x</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Java 11 Projects: Spring Boot 2.1.0 to 2.7.x, Spring Core 5.1.0 to 5.3.x, Spring WebFlux 5.1.0 to 5.3.x, Spring Boot Starter WebFlux 2.1.0 to 2.7.x</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Java 17 Projects: Spring Boot 2.4.0 to 4.0.x, Spring Core 5.3.1 to 7.0.x, Spring WebFlux 5.3.1 to 7.0.x, Spring Boot Starter WebFlux 2.4.0 to 4.0.x</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Java 21 Projects: Spring Boot 2.4.0 to 4.0.x, Spring Core 5.3.1 to 7.0.x, Spring WebFlux 5.3.1 to 7.0.x, Spring Boot Starter WebFlux 2.4.0 to 4.0.x</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Java 25 Projects: Spring Boot 3.2.4 to 4.0.x, Spring Core 6.2.0 to 7.0.x, Spring WebFlux 6.2.0 to 7.0.x, Spring Boot Starter WebFlux 3.2.4 to 4.0.x</td><td align="center">✅</td><td align="center">✅</td></tr></tbody></table>

Spring, Spring Boot and Spring WebFlux versions are required to be compatible with your version of Java, as well as each other.

### Supported Kotlin Versions

Currently all 64 bit versions of Kotlin are supported.

<table><thead><tr><th width="380.3333333333333">Kotlin</th><th width="196" align="center">Cover CLI</th><th align="center">Cover Plugin</th></tr></thead><tbody><tr><td>Kotlin</td><td align="center">✅</td><td align="center">✅</td></tr></tbody></table>

Note that Cover writes Java tests for Kotlin code, so you will also need a suitable Java installation with appropriate Java dependencies.

### Supported Build Tools

<table><thead><tr><th width="380.3333333333333">Tool</th><th width="196" align="center">Cover CLI</th><th align="center">Cover Plugin</th></tr></thead><tbody><tr><td>Gradle 4.9+ (must be <a href="https://docs.gradle.org/current/userguide/compatibility.html">compatible with your version of Java</a>).</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Maven 3.2.5+</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Ant 1.10.14+</td><td align="center">✅ <a href="/pages/4oQoqtd4e6HIGJg3RQaK">(requires setup)</a></td><td align="center">✅</td></tr></tbody></table>

### Supported Test Frameworks

<table><thead><tr><th width="379.3333333333333">Framework</th><th width="201" align="center">Cover CLI</th><th align="center">Cover Plugin</th></tr></thead><tbody><tr><td>JUnit 4 - 4.11 to 4.13</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>JUnit Jupiter 5 - 5.0 to 5.12.2</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>TestNG 6.0.1 to 7.10.2</td><td align="center">✅</td><td align="center">✅</td></tr></tbody></table>

#### JUnit 4

Diffblue Cover supports JUnit 4, from JUnit 4.11 to JUnit 4.13. In the CLI, you can force the usage of JUnit 4 by passing the `--testing-framework=junit-4` option. In the plugin, you can select `JUnit 4` as a testing framework in the settings dialog.

#### JUnit Jupiter 5

Diffblue Cover supports JUnit Jupiter, from JUnit Jupiter 5.0 to JUnit Jupiter 5.12.2 In the CLI, you can force the usage of JUnit 5 by passing the `--testing-framework=junit-5` option. In the plugin, you can select `JUnit 5` as a testing framework in the settings dialog.

You may need some specific set-up for your build system to work properly with JUnit 5, in particular if you wish to use Diffblue Cover's built-in test validation. See Building a Gradle project or Building a Maven project for details.

#### TestNG 6 and 7

Diffblue Cover supports TestNG versions 6 and 7. In the CLI, you can force the usage of TestNG by passing the `--testing-framework=testng` option. In the plugin, you can select `TestNG` as a testing framework in the settings dialog.

### Supported Mock Frameworks

### Supported JaCoCo Versions

<table><thead><tr><th width="383.3333333333333">JaCoCo</th><th width="202" align="center">Cover CLI</th><th align="center">Cover Plugin</th></tr></thead><tbody><tr><td>JaCoCo 0.8.3+ for Java 8 and 11</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>JaCoCo 0.8.7+ for Java 17</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>JaCoCo 0.8.11+ for Java 21</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>JaCoCo 0.8.14+ for Java 25</td><td align="center">✅</td><td align="center">✅</td></tr></tbody></table>

### Supported Jersey Versions

<table><thead><tr><th width="383.3333333333333">Jersey</th><th width="202" align="center">Cover CLI</th><th align="center">Cover Plugin</th></tr></thead><tbody><tr><td>Jersey 2</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Jersey 3</td><td align="center">✅</td><td align="center">✅</td></tr></tbody></table>

For Jersey 2 and 3 support, the following dependencies are required for test generation:

* `org.glassfish.jersey.test-framework:jersey-test-framework-core`
* `org.glassfish.jersey.test-framework.providers:jersey-test-framework-provider-inmemory`

### Coverage Measurement

<table><thead><tr><th width="388.3333333333333">Tool</th><th width="203" align="center">Cover CLI</th><th align="center">Cover Plugin</th></tr></thead><tbody><tr><td>Externally via JaCoCo, SonarQube etc.</td><td align="center">✅</td><td align="center">✅</td></tr></tbody></table>

### Creating Tests - Scope

<table><thead><tr><th width="389.3333333333333">Level</th><th width="198" align="center">Cover CLI</th><th align="center">Cover Plugin</th></tr></thead><tbody><tr><td>Per method</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Per class</td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Per package <strong>*</strong></td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Per module <strong>**</strong></td><td align="center">✅</td><td align="center">✅</td></tr><tr><td>Exclude methods from analysis</td><td align="center">✅</td><td align="center"></td></tr></tbody></table>

**\*** For Cover Plugin, this feature is **not** available in the Community Edition.

**\*\*** For Cover Plugin, this feature is **only** available in the Enterprise Edition.

### Cover Reports

<table><thead><tr><th width="396.3333333333333">Database</th><th align="center">Docker</th><th align="center">Zip</th></tr></thead><tbody><tr><td>Postgres 14*</td><td align="center">Included</td><td align="center">Optional</td></tr><tr><td>H2</td><td align="center"></td><td align="center">Included</td></tr></tbody></table>

\* For Cover Reports, when using our Docker distribution Postgres 14 is included. When using Zip distribution, H2 is included. However you can provide a self hosted Postgres 14 database for production purposes. We support vanilla Postgres 14. Postgres 15+ versions and alternative distributions can be used at your own risk.


# Reference Deployments

A Cover deployment consists of multiple components (Plugin, CLI, Pipeline, Reports), which need to be installed and configured to interact with your CI/CD infrastructure and among each other correctly.

{% hint style="info" %}
We strongly recommend to strictly follow below reference deployments as deviations from them can lead to a dysfunctional deployment.
{% endhint %}

Depending on the properties of your CI/CD system, Cover can integrate in a few different ways so that you get most from your Cover deployment:

1. [**No CI/CD System Available**](#reference-deployment-1-no-ci-cd-system-available): This is the most basic deployment which does not make use of a CI/CD system and thus entails most manual effort.
2. [**Minimal CI/CD System**](#reference-deployment-2-minimal-ci-cd-system): This deployment is suitable if you are not ready for creating tests in your CI/CD system, but still want to benefit from automated reporting.
3. [**Slow CI/CD System**](#reference-deployment-3-slow-ci-cd-system): This deployment is suitable if your CI/CD system tends to be slow on pull requests.
4. [**Fast CI/CD System**](#reference-deployment-4-fast-ci-cd-system): If your CI/CD system tends to be fast on pull requests then you can take advantage of writing and updating new tests on each pull request.

### Reference Deployment 1: No CI/CD System Available

This is the most basic deployment which does not make use of a CI/CD system and thus entails most manual effort. You have to trigger all actions manually from developer workstations. See diagram below.

<figure><img src="/files/msbjnrJror1KFYK25arv" alt=""><figcaption><p>Reference Deployment 1: No CI/CD System Available</p></figcaption></figure>

You need to [install Cover Reports](/features/cover-reports/cover-reports-administrator) on a central server and [Cover CLI ](/features/cover-cli/cover-cli-admin)and [Cover Plugin](/features/cover-plugin/cover-plugin-admin) on developer workstations. [Telemetry](/features/cover-cli/cover-cli-admin/telemetry) is configured on developer workstations so that you can track Diffblue usage.

The developer onboarding a new project *creates the initial test baseline* using Cover CLI and uploads coverage data to Cover Reports. On each Cover release, a developer refreshes the baseline using Cover CLI and uploads coverage data to Cover Reports in order to track test coverage across your projects. Developers use Cover Plugin day-to-day to write and update tests.

### Reference Deployment 2: Minimal CI/CD System

This deployment is suitable if you are not ready for creating tests in your CI/CD system, but still want to benefit from automated reporting. See diagram below. The difference to Reference Deployment 1 is that it automates uploading coverage data to Cover Reports, enabling more frequent tracking of test coverage across your projects.

<figure><img src="/files/Bonaq71SJZnw5RdhBjCf" alt=""><figcaption><p>Reference Deployment 2: Minimal CI/CD System</p></figcaption></figure>

You need to [install Cover Reports](/features/cover-reports/cover-reports-administrator) on a central server and [Cover CLI ](/features/cover-cli/cover-cli-admin)and [Cover Plugin](/features/cover-plugin/cover-plugin-admin) on developer workstations. [Telemetry](/features/cover-cli/cover-cli-admin/telemetry) is configured on developer workstations so that you can track Diffblue usage.

The developer onboarding a new project *creates the initial test baseline* using Cover CLI and uploads coverage data to Cover Reports. Developers use Cover Plugin day-to-day to write and update tests. CI is configured to run periodically, e.g. nightly, on the stable branch, e.g. main, of the project to create and upload coverage reports to Cover Reports in order to track test coverage across your projects. On each Cover release, the baseline is refreshed using Cover CLI and coverage data uploaded to Cover Reports.

### Reference Deployment 3: Slow CI/CD System

This deployment is suitable if your CI/CD system tends to be slow on pull requests. See diagram below. The difference to Reference Deployment 2 is that

* test baselines are triggered automatically and refreshed more frequently, and
* coverage data is automatically uploaded to Cover Reports on merging pull requests.

<figure><img src="/files/Wgm4MV05WurM5HpFK0YN" alt=""><figcaption><p>Reference Deployment 3: Slow CI/CD System</p></figcaption></figure>

You need to [install Cover Reports](/features/cover-reports/cover-reports-administrator) on a central server, [Cover Pipeline](/features/cover-pipeline) in your CI/CD system and [Cover CLI ](/features/cover-cli/cover-cli-admin)and [Cover Plugin](/features/cover-plugin/cover-plugin-admin) on developer workstations. [Telemetry](/features/cover-cli/cover-cli-admin/telemetry) is configured on developer workstations and in your CI/CD system so that you can track Diffblue usage.

The developer onboarding a new project *creates the initial test baseline* using Cover CLI and uploads coverage data to Cover Reports. Developers use Cover Plugin day-to-day to write and update tests. Coverage data is uploaded to Cover Reports whenever a pull request is merged in order to track test coverage across your projects. CI is configured to run periodically (e.g. weekly) to refresh the baseline and to upload coverage data to Cover Reports.

### Reference Deployment 4: Fast CI/CD System

If your CI/CD system tends to be fast on pull requests then you can take advantage of writing and updating new tests on each pull request. The difference to Reference Deployment 3 is that tests are added incrementally in the pull request workflow.

<figure><img src="/files/2CBtXJLtA7An3OncbnZi" alt=""><figcaption><p>Reference Deployment 4: Fast CI/CD System</p></figcaption></figure>

You need to [install Cover Reports](/features/cover-reports/cover-reports-administrator) on a central server, [Cover Pipeline](/features/cover-pipeline) in your CI/CD system and [Cover CLI ](/features/cover-cli/cover-cli-admin)and [Cover Plugin](/features/cover-plugin/cover-plugin-admin) on developer workstations. [Telemetry](/features/cover-cli/cover-cli-admin/telemetry) is configured on developer workstations and in your CI/CD system so that you can track Diffblue usage.

The developer onboarding a new project *creates the initial test baseline* using Cover CLI and uploads coverage data to Cover Reports. Developers use Cover Plugin day-to-day to write and update tests locally. When developers push their code then Cover writes new tests that developers haven't written locally, updates existing ones and commits the changes to their pull request branch. Coverage data is uploaded to Cover Reports whenever a pull request is merged in order to track test coverage across your projects. CI is configured to run periodically (e.g. weekly) to refresh the baseline and to upload coverage data to Cover Reports.


# Licensing

How Diffblue Cover is licensed and where to find licensing resources

## Activate a license

Follow these steps to activate a license. Note that:

* Cover Plugin Community Edition is free to use but does require product verification to activate your perpetual license.
* These steps cover online license activation only.
* Offline licensing for Cover CLI is available for Diffblue Cover Enterprise Edition only - see [#editions](#editions "mention") and [Offline license activation](/get-started/licensing/licensing-offline).

{% tabs %}
{% tab title="Cover Plugin" %}
Once you install Cover Plugin for IntelliJ, you'll be prompted for your license key to activate the plugin. Alternatively, the license can be activated at any time from the IntelliJ toolbar `Diffblue > Activate License`.

Diffblue Cover requires a remote license check with the Diffblue licensing server each time it's used. For help troubleshooting license keys, network connections, and proxy server settings, see [Online license activation](/get-started/licensing/licensing-online).

<figure><img src="/files/0SKxPD4QVPrjJQiM4rX0" alt="" width="563"><figcaption></figcaption></figure>

To check your current license details, go to the IntelliJ toolbar `Diffblue > View License Information`.
{% endtab %}

{% tab title="Cover CLI" %}
Diffblue Cover requires a remote license check with the Diffblue licensing server each time it's used. For help troubleshooting license keys, network connections, and proxy server settings, as well as details of offline licensing (Enterprise Edition only), see [Licensing](/get-started/licensing).

* To activate your license, from a Windows PowerShell (Windows) or Terminal (macOS/Linux) enter the command `dcover activate <license-key>` - replace `<license-key>` with the license key provided in your welcome email or provided by your organization.
* Entering multiple different license keys will overwrite the existing key.
* You can check your license status by running the command `dcover license`
  {% endtab %}
  {% endtabs %}

## Online & Offline

**Online license activation**

Diffblue Cover requires a remote license check with the Diffblue licensing server each time it's used. To perform the license check Diffblue Cover needs an active internet connection to the following servers:

* <https://licensing.diffblue.com/>
* <https://api.licensespring.com/>

The license check uses this connection to identify individual devices. Further details regarding the exact data exchanged are available in the [Privacy Notice](/legal/diffblue-legal/privacy-notice).

For more details, including troubleshooting, see the main [Online license activation](/get-started/licensing/licensing-online) topic.

**Offline license activation**

Diffblue Cover Enterprise Edition users with the offline option can activate 100% offline. This means Diffblue Cover can be used in secure and air-gapped environments with no external network connection required.

For more details, including troubleshooting, see the main [Offline license activation](/get-started/licensing/licensing-offline) topic.

## Editions

Diffblue Cover is licensed according to the four [pricing plans](https://www.diffblue.com/pricing/) which determine what features and limits apply to your use of Diffblue Cover. Please see [Cover Editions](/updates-and-upgrades/cover-editions) for more details.

## Diffblue license manager

According to the terms of your subscription, you may be given access to the [Diffblue License Management Portal](/get-started/licensing/licensing-manager) allowing you to see license use, manage license keys, and license users. License manager access is granted according to the exact license type purchased - it may not be applicable to your license type.


# Online license activation

How to activate your Diffblue Cover license online

## Requirements

Diffblue Cover requires a remote license check with the Diffblue licensing server each time it is used. *Offline license activation is available with the* [*Enterprise Edition*](/get-started/licensing#editions) *offline* *option only*.

To perform the license check Diffblue Cover needs an active internet connection to the following servers:

* <https://licensing.diffblue.com/>
* <https://api.licensespring.com/>

The license check uses this connection to identify individual devices. Further details regarding the exact data exchanged are available in the [Privacy Notice](/legal/diffblue-legal/privacy-notice).

## Activate a license

Follow these steps to activate a license. Note that:

* Cover Plugin Community Edition is free to use but does require product verification to activate your perpetual license.
* These steps cover online license activation only.
* Offline licensing for Cover CLI is available for Diffblue Cover Enterprise Edition only - see [Licensing](/get-started/licensing#editions) and [Offline license activation](/get-started/licensing/licensing-offline).

{% tabs %}
{% tab title="Cover Plugin" %}
Once you install Cover Plugin for IntelliJ, you'll be prompted for your license key to activate the plugin. Alternatively, the license can be activated at any time from the IntelliJ toolbar `Diffblue > Activate License`.

Diffblue Cover requires a remote license check with the Diffblue licensing server each time it's used. For help troubleshooting license keys, network connections, and proxy server settings, see [Online license activation](/get-started/licensing/licensing-online).

<figure><img src="/files/0SKxPD4QVPrjJQiM4rX0" alt="" width="563"><figcaption></figcaption></figure>

To check your current license details, go to the Intellij toolbar `Diffblue > View License Information`.
{% endtab %}

{% tab title="Cover CLI" %}
Diffblue Cover requires a remote license check with the Diffblue licensing server each time it's used. For help troubleshooting license keys, network connections, and proxy server settings, as well as details of offline licensing (Enterprise Edition only), see [Licensing](/get-started/licensing).

* To activate your license, from a Windows PowerShell (Windows) or Terminal (macOS/Linux) enter the command `dcover activate <license-key>` - replace `<license-key>` with the license key provided in your welcome email or provided by your organization.
* Entering multiple different license keys will overwrite the existing key.
* You can check your license status by running the command `dcover license`
  {% endtab %}
  {% endtabs %}

## Configuring a proxy server

{% tabs %}
{% tab title="Cover Plugin" %}
Please ensure you have the Proxy Server details configured in the IntelliJ settings page and then restart IntelliJ:

* **Windows and Linux:** `File > Settings > Appearance and Behavior > System Settings > HTTP Proxy`
* **macOS:** `IntelliJ IDEA > Preferences > Appearance and Behavior > System Settings > HTTP Proxy`

Please see the [HTTPS certificate errors](#troubleshooting-https-certificate-errors) information below.
{% endtab %}

{% tab title="Cover CLI" %}
Diffblue Cover CLI utilizes the system Java proxy configurations; these can be set via the environment variable `JVM_ARGS` which details the proxy server FQDN and port, for example:

```shell
JVM_ARGS="-Dhttps.proxyHost=proxy.domain.com -Dhttps.proxyPort=8080"
```

As shown in this example:

* `JVM_ARGS` passes extra options to the Java process from Diffblue Cover.
* Passing `-Dname=value` sets a system property. You can use system properties to set the proxy config as shown here: <https://docs.oracle.com/javase/8/docs/technotes/guides/net/proxies.html>

*Reminder: Ensure that the environment variable `JVM_ARGS` is set permanently according to your operating system instructions.*
{% endtab %}
{% endtabs %}

## Troubleshooting license server connections

1. Check you have an active internet connection at all times when using Diffblue Cover.
2. Ensure you can access `https://licensing.diffblue.com/` via a web browser; you will automatically receive a confirmation message when this is successful.
3. Ensure you can access `https://api.licensespring.com/` via a web browser, you should see the message "Welcome to the LicenseSpring API".
4. Ensure that any Proxy Server settings are correctly set up (see the bottom of this page).
5. Please speak to your network manager about allowing access to the URLs above, and checking that port 443 is open.
6. For Cover Plugin, restart IntelliJ.
7. Try temporarily disabling anti-virus, malware detector or any firewall software.
8. A detailed logfile is available which shows further diagnostic information about the license check process - please review the logs ([Cover Plugin Log Files](/features/cover-plugin/cover-plugin-admin/log-files), [Cover CLI Log Files](/features/cover-cli/cover-cli-admin/log-files)).

For further help troubleshooting licensing network connection issues, please contact [Diffblue Support](https://www.diffblue.com/support).


# Offline license activation

How to activate your Diffblue Cover license offline

Licensing Diffblue Cover in the offline mode detailed here is available **only** when purchased with the [Enterprise Edition](/updates-and-upgrades/cover-editions) offline option. To use Diffblue Cover in an offline environment, such as a high-security or air-gapped network, requires this [Enterprise Edition](/get-started/licensing#editions) offline option.

Otherwise Diffblue Cover requires a [remote license check](/get-started/licensing/licensing-online) with the Diffblue licensing server each time it is used.

## Activating an offline license

This section describes how to activate a Diffblue Cover offline license.

{% tabs %}
{% tab title="Cover Plugin" %}
Licensing the Diffblue Cover Plugin for IntelliJ in offline mode is performed using Cover CLI.

1. Install [Diffblue Cover Plugin](/get-started/get-started/get-started-cover-plugin) and install [Diffblue Cover CLI](/get-started/get-started/get-started-cover-cli).
2. Before entering a license key, completely exit all instances of the IntelliJ IDE. Note that closing the project window is not sufficient.
3. Follow the Cover CLI steps detailed in the tab above to activate your license in offline mode, using the Diffblue Cover CLI command `dcover activate --offline`
4. Restart the IntelliJ IDE.
5. You're now ready to write tests using Diffblue Cover Plugin.
   {% endtab %}

{% tab title="Cover CLI" %}
Activating Diffblue Cover CLI offline:

1. Install [Diffblue Cover CLI](/get-started/get-started/get-started-cover-cli).
2. Obtain your licence file and license key. To activate Diffblue Cover offline you will require your license file `ls_activation.lic`, along with your license key `XXXX-XXXX-XXXX-XXXX`. These can be obtained from:\
   \- Your Diffblue Cover welcome email received following license purchase.\
   \- Your organization's internal file/app/license store.\
   \- Or contact [Diffblue Support](https://www.diffblue.com/support) for help finding this information.
3. Run `dcover license` to prepare a directory for license installation:

```
➜  dcover license

12:55:23.365 INFO  Diffblue Cover 2022.02.02
12:55:23.368 INFO  There is no license linked to your product
```

This will create an `offline` directory at:

```
<USER_HOME>/.diffblue/offline/
```

4. Copy `ls_activation.lic` to the Diffblue offline license directory:
5. On Linux or macOS your home directory can be found at `~/.diffblue/offline/`
6. On Windows your user home can be found at `C:\Users\<username>\.diffblue\offline\`
7. Run `dcover activate --offline <license key>` to install the offline license:

```
➜  dcover activate --offline XXXX-XXXX-XXXX-XXXX

15:48:35.064 INFO  Found an offline license file at '<USER_HOME>/.diffblue/offline/ls_activation.lic'
15:48:35.494 INFO  Successfully activated offline license
```

6. You're now ready to write tests using Diffblue Cover CLI.
   {% endtab %}

{% tab title="Environment Variables (CLI and CI)" %}
Diffblue Cover CLI (also as used in Docker images and Diffblue Cover Pipelines) can be configured using environment variables. Please note that environment variables for offline license activation will not work for the plugin.

Obtain your license file and license key. To activate Diffblue Cover offline you will require your license file `ls_activation.lic`, along with your license key `XXXX-XXXX-XXXX-XXXX`. These can be obtained from:\
\- Your Diffblue Cover welcome email received following license purchase.\
\- Your organization's internal file/app/license store.\
\- Or contact [Diffblue Support](https://www.diffblue.com/support) for help finding this information.

Configure the following environment variables:

* `DIFFBLUE_OFFLINE_LICENSE_ACTIVATION_FILE_CONTENTS` with the contents of the `ls_activation.lic`
* `DIFFBLUE_LICENSE_KEY` with the value of your license key.

*Windows only note:* due to Windows environment variable size limitations (e.g. cmd.exe, Windows system variables, etc.), please configure using PowerShell to ensure the license activation file environment variable can be stored. Note that third party software such as git bash usually support larger environment variables.

You can now activate your license with

```
dcover activate --offline
```

{% endtab %}
{% endtabs %}

## Distributing an offline license

This section describes how to make an offline Enterprise license for Diffblue Cover available to users without them requiring their own activation or access to the license key. This is typically useful when users have managed environments where new software can be rolled out to their environment, or as an alternative to environment variables in a CI environment.

1. First, the license will need to be activated as above using the Diffblue Cover CLI and provided `ls_activation.lic` and license key, e.g.:\
   `dcover activate --offline <DIFFBLUE LICENSE KEY>`\
   this will put a `license.key` file into `<USER_HOME>/.diffblue/`.
2. The `license.key` file above can now be placed into the `<USER_HOME>/.diffblue` directory of any user and this will be recognized by Diffblue Cover (Plugin and CLI).


# Diffblue License Manager

Guide on how to log in and use the Diffblue license manager

## Logging in

The Diffblue license manager is for managing your organization's licenses. A license manager is assigned to each organization.

Log in to <https://licenses.diffblue.com> using the username and password provided in your Diffblue welcome email.

<div align="left"><figure><img src="/files/Otyjwp4crnZ0CspKIi7z" alt="" width="563"><figcaption></figcaption></figure></div>

## Dashboard

Once logged in you will be presented with a dashboard which currently lists how many licenses you are managing.

<div align="left"><figure><img src="/files/pR0QiFicd5ROtqNVfPhx" alt="" width="563"><figcaption></figcaption></figure></div>

## Orders

Click on the **Order** button on the left hand menu bar to get a list of the orders you are managing. Each order can have 1 or more licenses associated with it. Click on an order to see the licenses it contains.

<div align="left"><figure><img src="/files/rhAZhDajnuR0OufCztaL" alt="" width="563"><figcaption></figcaption></figure></div>

## Order details

After clicking on an order you will see this Order details page. There are several tabs you can click on.

<div align="left"><figure><img src="/files/87T0H8eNvahRHVNwgN2L" alt="" width="563"><figcaption></figcaption></figure></div>

If you click on **License managers** you can see a list of the license managers assigned to this order. You can also use the **Add license manager** button to add a new license manager.

<div align="left"><figure><img src="/files/KTybFru963MKMeKejR3P" alt="" width="563"><figcaption></figcaption></figure></div>

After clicking on the **Add license manager** button you will be given a short form to fill out. Input the email address, first name and last name. Take note of the automatically generated password or supply your own. These details are not automatically sent to the new license manager so you will have to email them yourself or provide them via some other channel.

<div align="left"><figure><img src="/files/UI0B2ZwpPQvmnY3DIqMG" alt="" width="563"><figcaption></figcaption></figure></div>

If you click on **Licenses** you will get a list of the license keys associated with the order. If there are many keys you will have multiple pages of licenses. The list includes the expiration date of the licenses and 'Status' indicates whether or not they have been activated.

<figure><img src="/files/pMLYzSfY0sFCh76ZHruQ" alt=""><figcaption></figcaption></figure>

## Licenses

If you click on one of the licenses in the license list you will be taken to a page with more information about that license. This page also has a button where you can reset the activations for that license.

<div align="left"><figure><img src="/files/rzwRGtBTXGXlqtSZkNaS" alt="" width="563"><figcaption></figcaption></figure></div>

## Devices

Clicking on the **Devices** tab on the License details screen will give you a list of all the devices that the license has been activated on. This includes information such as hostname and internal/external IP addresses.

<div align="left"><figure><img src="/files/W4UMYLN5sa883a9X6DKD" alt="" width="563"><figcaption></figcaption></figure></div>

## My profile

You can edit your license manager profile by clicking on the **My profile** button in the left hand menu. From here you can change your first name, last name and also change your password.

<div align="left"><figure><img src="/files/QEtma2tSveBXlZBsYygW" alt="" width="563"><figcaption></figcaption></figure></div>


# Update Cover

How to update Cover Plugin and Cover CLI to the latest version

Diffblue releases product updates about every two weeks to continuously provide you with product enhancements and new features. Note that:

* If needed, check the details for the latest updates, and even the older ones - see [What's new](/updates-and-upgrades/whats-new).
* When you update, you'll always be updated to the latest version.
* If you're using Cover Plugin **and** Cover CLI, we recommend that you update both products to the latest version.

{% tabs %}
{% tab title="Cover Plugin" %}
{% hint style="info" %}
Updating Cover Plugin may take a few minutes to complete and will require an IDE restart - you won't be able to create any tests for your projects while the update is progressing.
{% endhint %}

1. In IntelliJ, go to `File > Settings > Plugins` (Windows/Linux) or `IntelliJ IDEA > Preferences > Plugins` (macOS), highlight the Diffblue Plugin and click `Update` in the details panel.
2. When you're ready, click `Restart IDE` to complete the update.
   {% endtab %}

{% tab title="Cover CLI" %}
{% hint style="info" %}
Updating Cover CLI may take a few minutes to complete and you won't be able to create any tests for your projects while the update is progressing.
{% endhint %}

**Windows:**

1. Using the link provided by Diffblue, download the new Diffblue Cover CLI file - either the `.exe` installer or `.zip` archive, as needed.
2. If you use the installer, run the `.exe` installer and follow the on-screen prompts.
3. If you use the archive file, extract the `.zip` file to your existing Cover CLI folder. Note that if you'd like to retain the previous release files, move these to a different folder first or create a new folder for the new version. Make sure to update the `PATH` or `DCOVER` environment variable configured during your original install, if needed.
4. When your done, restart your PC. Once complete, run `dcover version` to check the install and `PATH` configuration - if all is OK, Cover will display the current version.

**Linux/macOS:**

1. Using the link provided by Diffblue, download the Diffblue Cover CLI `.zip` file.
2. Unzip the Cover CLI zip file to an appropriate installation location using the following example commands. Note that if you'd like to retain the previous release files, move these to a different folder first or create a new folder for the new version. Make sure to update the `PATH` environment variable configured during your original install, if needed.\\

   ```
   mkdir ~/bin
   cd ~/bin
   unzip ~/diffblue-cover*.zip
   export PATH=$PATH:~/bin
   ```

   \
   **Reminder:** Make sure that the `PATH` environment variable is set permanently according to your operating system instructions.
3. Once complete, run `dcover version` to check the install and `PATH` configuration - if all is OK, Cover will display the current version.
   {% endtab %}
   {% endtabs %}

**Note:** To update Cover Reports, see [Install and update Cover Reports](/features/cover-reports/cover-reports-administrator/installation).


# FAQs

The things we get asked the most. Always worth a look.

<details>

<summary>What is Diffblue Cover?</summary>

Diffblue Cover is a reinforcement learning AI platform that automatically writes comprehensive, human-like Java unit tests. Cover is provided as an IDE plugin (Cover **Plugin**) and a CLI application (Cover **CLI**) for developer use and can also be integrated into your CI Pipeline (Cover **Pipeline**). We've also added three reporting and optimization tools for further monitoring and management control (Cover **Reports**, Cover **Optimize**, and Cover **Refactor**).

See [What is Diffblue Cover?](/get-started/what-is-diffblue-cover) for more details and to view our intro video.

</details>

<details>

<summary>Do I have to upload my code to a cloud service?</summary>

No. Cover Plugin and Cover CLI are used on developer workstations and Cover Pipeline operates within your CI environment.

</details>

<details>

<summary>What are the benefits of using Diffblue Cover?</summary>

Diffblue Cover helps your team increase automation of your CI pipeline.

For development teams, this:

* Improves velocity and quality of the software you deliver.
* Frees up time to focus on creating new features.

For DevOps teams, this:

* Helps catch errors and issues earlier (shift left!).
* Improves deployment frequency, lead time, and mean time to repair (MTTR).

See Diffblue Cover [What is Diffblue Cover?](/get-started/what-is-diffblue-cover#in-summary) for more details.

</details>

<details>

<summary>Will the tests find regressions in my code?</summary>

Yes. Diffblue Cover quickly generates tests that will allow you to adopt CI. The generated tests will help developers quickly identify regressions in subsequent commits before committing new versions.

</details>

<details>

<summary>What are the requirements for running Diffblue Cover?</summary>

**Basic pre-requisites:**

* Java 8, 11, 17, or 21 compatible source code, or Kotlin source code.
* Maven 3.2.5+, Gradle 4.9+, or Ant 1.10.14+ build tools.
* The project (for use with Diffblue Cover) must compile and run with no failing unit tests. JUnit and TestNG testing frameworks are supported.

**More details:**

Diffblue Cover requires that the system environment (hardware, operating system, network connectivity, Java installation) as well as the project environment (build tooling, dependencies, presence of artifacts, existing unit tests) meet the minimum requirements as detailed in [Specs & Reqs](/get-started/specs-and-reqs). Diffblue Cover will perform an environment check before analysis begins to ensure that the requirements are met - if there are any issues, these will be reported using [Output Codes](/features/output-codes).

Note that you can run `dcover create --preflight` (using [Diffblue Cover CLI](/get-started/get-started/get-started-cover-cli)) to check the Cover pre-requisites for your project, without performing any other actions.

</details>

<details>

<summary>How can I learn more about customers using Diffblue Cover?</summary>

See our [case study](https://www.diffblue.com/goldman-sachs/) on how Goldman Sachs has benefited from using Diffblue Cover to increase coverage and create a safety net against regressions.

For examples of other ways our customers use Diffblue Cover, [click here](https://www.diffblue.com/use-cases/).

</details>

<details>

<summary>How do we maintain Diffblue unit tests in the future?</summary>

Diffblue regression suites are maintained automatically and updated with each new code version to capture the current behavior of the code.

</details>

<details>

<summary>How does Diffblue Cover help me adopt Continuous Integration?</summary>

Diffblue Cover AI analyzes your code and writes Java unit tests that run in a CI pipeline after each commit. Cover’s tests:

* Always compile.
* Run quickly.
* Detect regressions from previous versions.
* Improve coverage.
* Are easy to understand.

</details>

<details>

<summary>Should our team stop writing unit tests after adopting Diffblue Cover?</summary>

No. Diffblue Cover is meant to complement your own unit tests and help you catch regressions.

</details>

<details>

<summary>How is a unit test different from a Diffblue regression suite?</summary>

Developers write individual unit tests to test specific functionality. Diffblue regression suites are generated automatically to help find regressions early in the development cycle. Find out more in our [Unit Regression Tests eBook](https://www.diffblue.com/Testing/ebooks/unit-regression-tests/).

</details>


# Diffblue Learning

Get the most out of Diffblue Cover - Read, Watch, Learn - select the guided learning path to get what you need.

## Get started

Get started with Diffblue Cover - download, install, license, and play:

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Just the basics</strong></td><td>Diffblue Cover basic concepts.</td><td></td><td></td><td><a href="/pages/zp9kqrHTWcROJ5Aot0T5">/pages/zp9kqrHTWcROJ5Aot0T5</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Free Trial</strong></td><td>Get started with the free trial (IDE <strong>and</strong> Command Line) and create tests for a sample project.</td><td></td><td></td><td><a href="/pages/BynAWHODbfEaoLTExXvq">/pages/BynAWHODbfEaoLTExXvq</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Cover Plugin (IDE)</strong></td><td>A focus on the IntelliJ IDE. Get started with Cover Plugin and create tests for sample methods and classes directly in your IDE.</td><td></td><td></td><td><a href="/pages/q9DM9a3vj2nUpgXIV4Tf">/pages/q9DM9a3vj2nUpgXIV4Tf</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Cover CLI (Command Line)</strong></td><td>A focus on the command line. Get started with Cover CLI and create tests for an entire sample project using the CLI tool.</td><td></td><td></td><td><a href="/pages/vwcf3CiciW8dQZPOBMFl">/pages/vwcf3CiciW8dQZPOBMFl</a></td></tr></tbody></table>

#### Achievements:

* [x] Learn what Diffblue Cover is and how it works.
* [x] Know how to download, install, and license Diffblue Cover.
* [x] Know how to use Diffblue Cover to write tests (basic concepts) and how to start applying this to your own code.

## **Developer**

Detailed learning paths targeted at developers:

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Unit Tests - IDE</strong></td><td>Use Diffblue Cover within the IntelliJ IDE to create tests for your methods and classes.</td><td></td><td><a href="/pages/glzIcKFv6sW49Nao69mC">/pages/glzIcKFv6sW49Nao69mC</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Unit Tests - CLI</strong></td><td>Use Diffblue Cover from a command line to create tests for your projects.</td><td></td><td><a href="/pages/Eyttr3yp8ImRirfON43W">/pages/Eyttr3yp8ImRirfON43W</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Test Coverage</strong></td><td>Create coverage reports and improve test coverage.</td><td></td><td><a href="/pages/hiaZKocqUOo7clxq7Vj8">/pages/hiaZKocqUOo7clxq7Vj8</a></td></tr></tbody></table>

#### Achievements:

* [x] Understand Diffblue Cover specifications and requirements and how to configure your projects for automated test writing.
* [x] Know how to use Diffblue Cover to write tests for your projects - basic and advanced concepts.
* [x] Understand output codes and how to resolve them.
* [x] Know how to improve test coverage for your code base, including automated refactoring.

## **DevOps**

Detailed learning paths targeted at DevOps:

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>GitHub</strong></td><td>Integrate the Diffblue Cover Action into your GitHub workflows.</td><td></td><td><a href="/pages/2jZ20nXnaKa3Q8yVOxti">/pages/2jZ20nXnaKa3Q8yVOxti</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>GitLab</strong></td><td>Incorporate the Diffblue Cover Project Integration into your GitLab pipeline.</td><td></td><td><a href="/pages/q8fInfSpZjKxkcElqoU4">/pages/q8fInfSpZjKxkcElqoU4</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Other CI</strong></td><td>Integrate Cover CLI into your CI pipeline workflow - Jenkins, Azure, AWS.</td><td></td><td><a href="/pages/NBBIl5WiV6njbOfNk5Pp">/pages/NBBIl5WiV6njbOfNk5Pp</a></td></tr></tbody></table>

#### Achievements:

* [x] Understand the use of Diffblue Cover within a CI/CD environment.
* [x] Know how to activate and configure Cover Pipeline within your chosen CI/CD tool - initial setup and additional config options.
* [x] Know how to use Cover Pipeline to write tests for your projects - basic and advanced concepts.

## Administrator

Detailed learning paths targeted at "administrators" - manage and maintain Diffblue Cover for you, or your organization:

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Admin - IntelliJ</strong></td><td>Install, manage, and maintain Cover Plugin.</td><td></td><td><a href="/pages/wg5tzP7mPb3gHcZdfyF3">/pages/wg5tzP7mPb3gHcZdfyF3</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Admin - CLI</strong></td><td>Install, manage, and maintain Cover CLI.</td><td></td><td><a href="/pages/jHRORHbkETxJS10mLbcT">/pages/jHRORHbkETxJS10mLbcT</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Admin - Reports</strong></td><td>Install, manage, and maintain Cover Reports.</td><td></td><td><a href="/pages/ne2tVHESFos3ifm12mhl">/pages/ne2tVHESFos3ifm12mhl</a></td></tr></tbody></table>

#### Achievements:

* [x] Understand how to install, update, manage, and maintain Diffblue Cover, including config options and license management.

## Test coverage

Improve, monitor, and manage your test coverage:

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Developer</strong></td><td>Generate and upload Cover Reports bundles.</td><td></td><td><a href="/pages/9PDxCPRetrOBD85McUrS">/pages/9PDxCPRetrOBD85McUrS</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Senior Developer</strong></td><td>Use Cover Reports to monitor and manage test coverage.</td><td></td><td><a href="/pages/JyZmXGYsLr8FP6gfR7xA">/pages/JyZmXGYsLr8FP6gfR7xA</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Administrator</strong></td><td>Manage and maintain your Cover Reports instance.</td><td></td><td><a href="/pages/gIedWMkiEPbbN9yivkMz">/pages/gIedWMkiEPbbN9yivkMz</a></td></tr></tbody></table>

#### Achievements:

* [x] Know how to improve, monitor, and manage your test coverage.
* [x] Know how to improve test coverage for your code base, including automated refactoring.
* [x] Understand output codes and how to resolve them.
* [x] Understand how to use Cover Reports to monitor and manage test coverage.
* [x] Know how to manage your Cover Reports instance including installation, database backups, and software updates.


# Get started

Get started with Diffblue Cover - download, install, license, and play:

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Just the basics</strong></td><td>Diffblue Cover basic concepts.</td><td></td><td><a href="/pages/zp9kqrHTWcROJ5Aot0T5">/pages/zp9kqrHTWcROJ5Aot0T5</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Free trial</strong></td><td>Get started with the free trial (IDE <strong>and</strong> Command Line) and create tests for a sample project.</td><td></td><td><a href="/pages/BynAWHODbfEaoLTExXvq">/pages/BynAWHODbfEaoLTExXvq</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Cover Plugin (IDE)</strong></td><td>A focus on the IntelliJ IDE. Get started with Cover Plugin and create tests for sample methods and classes directly in your IDE.</td><td></td><td><a href="/pages/q9DM9a3vj2nUpgXIV4Tf">/pages/q9DM9a3vj2nUpgXIV4Tf</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Cover CLI (Command Line)</strong></td><td>A focus on the command line. Get started with Cover CLI and create tests for an entire sample project using the CLI tool.</td><td></td><td><a href="/pages/vwcf3CiciW8dQZPOBMFl">/pages/vwcf3CiciW8dQZPOBMFl</a></td></tr></tbody></table>

#### Achievements:

* [x] Learn what Diffblue Cover is and how it works.
* [x] Know how to download, install, and license Diffblue Cover.
* [x] Know how to use Diffblue Cover to write tests (basic concepts) and how to start applying this to your own code.


# Just the basics

Just need to know the basics? You've come to the right place.

## Start here...

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>What is Diffblue Cover</strong></td><td>[8 min read]</td><td>An introduction and overview of Diffblue Cover including features, benefits, and how it works.</td><td></td><td></td><td><a href="/pages/JuNKt6UxiiRtm5c1hF39">/pages/JuNKt6UxiiRtm5c1hF39</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Cover Editions</strong></td><td>[2 min read]</td><td>A summary of features and restrictions for each Diffblue Cover Edition.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/DUfIj2mMIGyS3o0NPnTy">/pages/DUfIj2mMIGyS3o0NPnTy</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Specs &#x26; Reqs</strong></td><td>[reference topic]</td><td>Reference details - specifications and requirements.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/pDoeGe6cmbIF025UbKoh">/pages/pDoeGe6cmbIF025UbKoh</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Writing Tests - IDE</strong></td><td>[2 min read]</td><td>A summary of how to write tests using Cover Plugin in IntelliJ.</td><td></td><td></td><td><a href="/pages/ZftYR0DSkDUlwJeZB4qc">/pages/ZftYR0DSkDUlwJeZB4qc</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Writing Tests - Command Line</strong></td><td>[2 min read]</td><td>A summary of how to write tests from a command line.</td><td></td><td></td><td><a href="/pages/jJZ7S2eFGuIm8lUnxxHl">/pages/jJZ7S2eFGuIm8lUnxxHl</a></td></tr><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>GitHub Actions - Intro</strong></td><td>[3 min watch]</td><td>Introducing Cover Pipeline for GitHub - Diffblue's GitHub Actions workflow.</td><td></td><td></td><td><a href="https://youtu.be/blxHRCYD1kA">https://youtu.be/blxHRCYD1kA</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>GitHub Actions - Overview</strong></td><td>[2 min read]</td><td>An overview of Cover Pipeline for GitHub - Diffblue's GitHub Actions workflow.</td><td></td><td></td><td><a href="/pages/ALwJtSUKr34i2lKJho17">/pages/ALwJtSUKr34i2lKJho17</a></td></tr><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>GitLab Integration - Intro</strong></td><td>[4 min watch]</td><td>Introducing Cover Pipeline for GitLab - Diffblue's GitLab project integration.</td><td></td><td></td><td><a href="https://youtu.be/7UBOTJzjF1E">https://youtu.be/7UBOTJzjF1E</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>GitLab Integration - Overview</strong></td><td>[2 min read]</td><td>An overview of Cover Pipeline for GitHub - Diffblue's GitLab project integration.</td><td></td><td></td><td><a href="/pages/1jmsci0qCK4XQkRTTPeD">/pages/1jmsci0qCK4XQkRTTPeD</a></td></tr></tbody></table>

## Next steps...

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Diffblue Cover Free Trial</strong></td><td>[7 min watch]</td><td>Sit back and watch while we demonstrate the Diffblue Cover free trial.</td><td></td><td><a href="https://youtu.be/CnDKtCrwnrI">https://youtu.be/CnDKtCrwnrI</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Diffblue Cover Free Trial</strong></td><td>[learning path]</td><td>Go beyond the demo and try it out for yourself - our full free trial learning path.</td><td></td><td><a href="/pages/BynAWHODbfEaoLTExXvq">/pages/BynAWHODbfEaoLTExXvq</a></td></tr></tbody></table>


# Free trial

Trying out Diffblue Cover for the first time? Get up and running with the trial version of our two core developer tools - Cover Plugin for IntelliJ and Cover CLI.

{% hint style="info" %}
Interested in integrating Diffblue Cover into your CI/CD pipeline? Jump over to the [DevOps Learning Paths](/get-started/diffblue-learning/devops).
{% endhint %}

## Start here...

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>What is Diffblue Cover</strong></td><td>[8 min read]</td><td>An introduction and overview of Diffblue Cover including features, benefits, and how it works.</td><td></td><td></td><td><a href="/pages/JuNKt6UxiiRtm5c1hF39">/pages/JuNKt6UxiiRtm5c1hF39</a></td></tr><tr><td><img src="/files/GMxVix3Kxsh9Ca9DIxN9" alt="" data-size="original"> <strong>Free Trial Registration</strong></td><td>[1 min sign-up]</td><td>If you haven't signed up for the trial yet, use this link to provide your details and get your license code.</td><td><strong>Title</strong></td><td></td><td><a href="https://diffblue.com/try-cover">https://diffblue.com/try-cover</a></td></tr><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Free Trial Video</strong></td><td>[7 min watch]</td><td>Sit back and watch while we demonstrate how to download, install, license, and use Cover Plugin and Cover CLI to write tests for a sample project.</td><td><strong>Title</strong></td><td></td><td><a href="https://youtu.be/CnDKtCrwnrI">https://youtu.be/CnDKtCrwnrI</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Free Trial Docs</strong></td><td>[12 min read]</td><td>Step-by-step details of how to download, install, license, and use Cover Plugin and Cover CLI to write tests for a sample project.</td><td></td><td></td><td><a href="/pages/Xvlm09AC7hewEt2hEyyH">/pages/Xvlm09AC7hewEt2hEyyH</a></td></tr></tbody></table>

## Alternatives...

When you want to use the free trial, but you're only interested in using Diffblue Cover within an IDE, or via a command line:

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Get Started Video - IDE Only</strong></td><td>[5 min watch]</td><td>A demonstration of how to download, install, license, and use Cover Plugin to write tests for a sample project.</td><td><strong>Title</strong></td><td></td><td><a href="https://youtu.be/wQ-W8Q5FYBU">https://youtu.be/wQ-W8Q5FYBU</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Get Started Docs - IDE Only</strong></td><td>[8 min read]</td><td>Step-by-step details of how to download, install, license, and use Cover Plugin to write tests for a sample project.</td><td></td><td></td><td><a href="/pages/Ios2MK7nZhRtOElluf0u">/pages/Ios2MK7nZhRtOElluf0u</a></td></tr><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Get Started Video - CLI Only</strong></td><td>[7 min watch]</td><td>A demonstration of how to download, install, license, and use Cover CLI to write tests for a sample project.</td><td></td><td></td><td><a href="https://youtu.be/eZkDQsYM9fA">https://youtu.be/eZkDQsYM9fA</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Get Started Docs - CLI Only</strong></td><td>[8 min read]</td><td>Step-by-step details of how to download, install, license, and use Cover CLI to write tests for a sample project.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/7V85GXh1MOFovvH55h1E">/pages/7V85GXh1MOFovvH55h1E</a></td></tr></tbody></table>

## Next steps...

Now you've got the basics, move on to the core learning paths for Cover Plugin and Cover CLI - these provide detailed guided learning paths for each product:

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Developer - Cover Plugin</strong></td><td>Use Cover Plugin to write tests for your own projects.</td><td><strong>Title</strong></td><td></td><td></td><td><a href="/pages/glzIcKFv6sW49Nao69mC">/pages/glzIcKFv6sW49Nao69mC</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Administrator - Cover Plugin</strong></td><td>General admin tasks.</td><td></td><td></td><td></td><td><a href="/pages/wg5tzP7mPb3gHcZdfyF3">/pages/wg5tzP7mPb3gHcZdfyF3</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Developer - Cover CLI</strong></td><td>Use Cover CLI to write tests for your own projects.</td><td></td><td></td><td></td><td><a href="/pages/Eyttr3yp8ImRirfON43W">/pages/Eyttr3yp8ImRirfON43W</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Administrator - Cover CLI</strong></td><td>General admin tasks.</td><td><strong>Title</strong></td><td></td><td></td><td><a href="/pages/jHRORHbkETxJS10mLbcT">/pages/jHRORHbkETxJS10mLbcT</a></td></tr></tbody></table>


# Cover Plugin (IDE)

Trying out Diffblue Cover for the first time? Get up and running with the trial version of Cover Plugin for IntelliJ and start writing unit tests for your methods and classes directly in your IDE.

## Start here...

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>What is Diffblue Cover</strong></td><td>[8 min read]</td><td>An introduction and overview of Diffblue Cover including features, benefits, and how it works.</td><td></td><td></td><td><a href="/pages/JuNKt6UxiiRtm5c1hF39">/pages/JuNKt6UxiiRtm5c1hF39</a></td></tr><tr><td><img src="/files/GMxVix3Kxsh9Ca9DIxN9" alt="" data-size="original"> <strong>Free Trial Registration</strong></td><td>[1 min sign-up]</td><td>If you haven't signed up for the trial yet, use this link to provide your details and get your license code.</td><td><strong>Title</strong></td><td></td><td><a href="https://diffblue.com/try-cover">https://diffblue.com/try-cover</a></td></tr><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Getting Started Video</strong></td><td>[5 min watch]</td><td>Sit back and watch while we demonstrate how to download, install, license, and use Cover Plugin for IntelliJ.</td><td><strong>Title</strong></td><td></td><td><a href="https://youtu.be/wQ-W8Q5FYBU">https://youtu.be/wQ-W8Q5FYBU</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Getting Started Docs</strong></td><td>[8 min read]</td><td>Step-by-step details of how to download, install, license, and use Cover Plugin to write tests for a sample project.</td><td></td><td></td><td><a href="/pages/Ios2MK7nZhRtOElluf0u">/pages/Ios2MK7nZhRtOElluf0u</a></td></tr></tbody></table>

## Alternatives...

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Get Started Video - Cover CLI</strong></td><td>[7 min watch]</td><td>A demonstration of how to download, install, license, and use Cover CLI to write tests for a sample project.</td><td></td><td></td><td><a href="https://youtu.be/eZkDQsYM9fA">https://youtu.be/eZkDQsYM9fA</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Get Started - Cover CLI</strong></td><td>[8 min read]</td><td>Step-by-step details of how to download, install, license, and use Cover CLI to write tests for a sample project.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/7V85GXh1MOFovvH55h1E">/pages/7V85GXh1MOFovvH55h1E</a></td></tr></tbody></table>

## Next steps...

Now you've got the basics, move on to the core learning paths for Cover Plugin:

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Developer - Cover Plugin</strong></td><td>Use Cover Plugin to write tests for your own projects.</td><td><strong>Title</strong></td><td></td><td></td><td><a href="/pages/glzIcKFv6sW49Nao69mC">/pages/glzIcKFv6sW49Nao69mC</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Administrator - Cover Plugin</strong></td><td>General admin tasks.</td><td></td><td></td><td></td><td><a href="/pages/wg5tzP7mPb3gHcZdfyF3">/pages/wg5tzP7mPb3gHcZdfyF3</a></td></tr></tbody></table>


# Cover CLI (Command Line)

Trying out Diffblue Cover for the first time? Get up and running with the trial version of Cover CLI and start writing unit tests for your projects from the command line.

{% hint style="info" %}
Interested in integrating Diffblue Cover into your CI/CD pipeline? Jump over to the [DevOps Learning Paths](/get-started/diffblue-learning/devops).
{% endhint %}

## Start here...

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>What is Diffblue Cover</strong></td><td>[8 min read]</td><td>An introduction and overview of Diffblue Cover including features, benefits, and how it works.</td><td></td><td></td><td><a href="/pages/JuNKt6UxiiRtm5c1hF39">/pages/JuNKt6UxiiRtm5c1hF39</a></td></tr><tr><td><img src="/files/GMxVix3Kxsh9Ca9DIxN9" alt="" data-size="original"> <strong>Free Trial Registration</strong></td><td>[1 min sign-up]</td><td>If you haven't signed up for the trial yet, use this link to provide your details and get your license code.</td><td><strong>Title</strong></td><td></td><td><a href="https://diffblue.com/try-cover">https://diffblue.com/try-cover</a></td></tr><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Getting Started Video</strong></td><td>[7 min watch]</td><td>A demonstration of how to download, install, license, and use Cover CLI to write tests for a sample project.</td><td><strong>Title</strong></td><td></td><td><a href="https://youtu.be/eZkDQsYM9fA">https://youtu.be/eZkDQsYM9fA</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Getting Started Docs</strong></td><td>[8 min read]</td><td>Step-by-step details of how to download, install, license, and use Cover CLI to write tests for a sample project.</td><td></td><td></td><td><a href="/pages/7V85GXh1MOFovvH55h1E">/pages/7V85GXh1MOFovvH55h1E</a></td></tr></tbody></table>

## Alternatives...

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Get Started Video - Cover Plugin</strong></td><td>[5 min watch]</td><td>A demonstration of how to download, install, license, and use Cover Plugin to write tests for a sample project.</td><td><strong>Title</strong></td><td></td><td><a href="https://youtu.be/wQ-W8Q5FYBU">https://youtu.be/wQ-W8Q5FYBU</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Get Started Docs - Cover Plugin</strong></td><td>[8 min read]</td><td>Step-by-step details of how to download, install, license, and use Cover Plugin to write tests for a sample project.</td><td></td><td></td><td><a href="/pages/Ios2MK7nZhRtOElluf0u">/pages/Ios2MK7nZhRtOElluf0u</a></td></tr></tbody></table>

## Next steps...

Now you've got the basics, move on to the core learning paths for Cover CLI:

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Developer - Cover CLI</strong></td><td>Use Cover CLI to write tests for your own projects.</td><td></td><td></td><td></td><td><a href="/pages/Eyttr3yp8ImRirfON43W">/pages/Eyttr3yp8ImRirfON43W</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Administrator - Cover CLI</strong></td><td>General admin tasks.</td><td><strong>Title</strong></td><td></td><td></td><td><a href="/pages/jHRORHbkETxJS10mLbcT">/pages/jHRORHbkETxJS10mLbcT</a></td></tr></tbody></table>


# Developer

Detailed learning paths targeted at developers:

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Unit Tests - IDE</strong></td><td>Use Diffblue Cover within the IntelliJ IDE to create tests for your methods and classes.</td><td></td><td><a href="/pages/glzIcKFv6sW49Nao69mC">/pages/glzIcKFv6sW49Nao69mC</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Unit Tests - CLI</strong></td><td>Use Diffblue Cover from a command line to create tests for your projects.</td><td></td><td><a href="/pages/Eyttr3yp8ImRirfON43W">/pages/Eyttr3yp8ImRirfON43W</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Test Coverage</strong></td><td>Create coverage reports and improve test coverage.</td><td></td><td><a href="/pages/hiaZKocqUOo7clxq7Vj8">/pages/hiaZKocqUOo7clxq7Vj8</a></td></tr></tbody></table>

#### Achievements:

* [x] Understand Diffblue Cover specifications and requirements and how to configure your projects for automated test writing.
* [x] Know how to use Diffblue Cover to write tests for your projects - basic and advanced concepts.
* [x] Understand output codes and how to resolve them.
* [x] Know how to improve test coverage for your code base, including automated refactoring.


# Unit tests (IDE)

Use Diffblue Cover within the IntelliJ IDE to create tests for your methods and classes.

{% hint style="info" %}
Before starting this learning path, we recommend that you first complete the [Cover Plugin Get Started](/get-started/diffblue-learning/get-started/cover-plugin-ide) path.
{% endhint %}

## Start here...

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Writing Tests</strong></td><td>[2 min read]</td><td>A summary of how to write tests using Cover Plugin in IntelliJ.</td><td></td><td></td><td><a href="/pages/ZftYR0DSkDUlwJeZB4qc">/pages/ZftYR0DSkDUlwJeZB4qc</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Gutter Icons</strong></td><td>[2 min read]</td><td>A summary of gutter icons features.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/H9LZtPMiJPWmU92BMWFN">/pages/H9LZtPMiJPWmU92BMWFN</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Menu Options</strong></td><td>[2 min read ]</td><td>A summary of the Diffblue menu options.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/Dti3AM5yb7IYXls9Atm6">/pages/Dti3AM5yb7IYXls9Atm6</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Test Examples</strong></td><td>[5 min read]</td><td>Unit test examples of varying complexity.</td><td></td><td></td><td><a href="/pages/9WyIVldDLYYFUoLamLVj">/pages/9WyIVldDLYYFUoLamLVj</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Project Configuration &#x26; Dependencies</strong></td><td>[3 min read]</td><td>Making sure your project configuration and dependencies meet the requirements needed to use Diffblue Cover.</td><td></td><td></td><td><a href="/pages/o9wMDReRjHqbTuq3qeac">/pages/o9wMDReRjHqbTuq3qeac</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Specs &#x26; Reqs</strong></td><td>[reference topic]</td><td>Reference details - Diffblue Cover specifications and requirements.</td><td></td><td></td><td><a href="/pages/pDoeGe6cmbIF025UbKoh">/pages/pDoeGe6cmbIF025UbKoh</a></td></tr></tbody></table>

## Know more...

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Output Codes</strong></td><td>[5 reference topics]</td><td>Reference details - Diffblue Cover output codes, messages, and descriptions.</td><td></td><td></td><td><a href="/pages/NesTdPaeLWtiOqUPTgND">/pages/NesTdPaeLWtiOqUPTgND</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Working With Output Codes</strong></td><td>[12 topics]</td><td>Useful hints and tips to help resolve a range of output codes.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/Kjj38nxdpW3Yo9eupAaH">/pages/Kjj38nxdpW3Yo9eupAaH</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Run Configurations</strong></td><td>[4 min read ]</td><td>Configure the environment variables and system properties used when Cover Plugin creates tests.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/XL3e86vr9n1K2LCzMxNb">/pages/XL3e86vr9n1K2LCzMxNb</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Settings</strong></td><td>[3 min read]</td><td>A summary of available Cover Plugin settings.</td><td></td><td></td><td><a href="/pages/EdoIpG8mg32SMjN2Unrn">/pages/EdoIpG8mg32SMjN2Unrn</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Partial Tests</strong></td><td>[4 min read]</td><td>Creating partial (incomplete) tests.</td><td></td><td></td><td><a href="/pages/W6ak8cqvfSttp0LaYhq2">/pages/W6ak8cqvfSttp0LaYhq2</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Skeleton Tests</strong></td><td>[4 min read]</td><td>Creating skeleton (outline) tests.</td><td></td><td></td><td><a href="/pages/yf0dbTzwwvvdajxBTxCA">/pages/yf0dbTzwwvvdajxBTxCA</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Test Naming</strong></td><td>[4 min read]</td><td>Test naming config and defaults.</td><td></td><td></td><td><a href="/pages/uH78HDqtzABFUApYjj3H">/pages/uH78HDqtzABFUApYjj3H</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Test Formatting</strong></td><td>[4 min read]</td><td>Configure the format of tests written by Cover Plugin.</td><td></td><td></td><td><a href="/pages/WloXHzznJhKxiy4vLh5y">/pages/WloXHzznJhKxiy4vLh5y</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Test Insertion Order</strong></td><td>[2 min read]</td><td>Test method ordering in test classes.</td><td></td><td></td><td><a href="/pages/pKDxuBmC8jzfzRDwF1q6">/pages/pKDxuBmC8jzfzRDwF1q6</a></td></tr></tbody></table>

## Next steps...

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Cover Plugin Admin</strong></td><td>Manage and maintain Cover Plugin.</td><td></td><td></td><td><a href="/pages/wg5tzP7mPb3gHcZdfyF3">/pages/wg5tzP7mPb3gHcZdfyF3</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Test Coverage</strong></td><td>Improve and manage test coverage.</td><td></td><td></td><td><a href="/pages/hiaZKocqUOo7clxq7Vj8">/pages/hiaZKocqUOo7clxq7Vj8</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Tutorials</strong></td><td>A range of tutorials covering topics such as implementing a code change and working with Kotlin projects.</td><td></td><td></td><td><a href="/pages/QRCujrjPS1ZqlXeapQTO">/pages/QRCujrjPS1ZqlXeapQTO</a></td></tr></tbody></table>


# Unit tests (CLI)

Use Diffblue Cover from a command line to create tests for your projects.

{% hint style="info" %}
Before starting this learning path, we recommend that you first complete the [Cover CLI Get Started](/get-started/diffblue-learning/get-started/cover-cli-command-line) path.
{% endhint %}

## Start here...

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Writing Tests</strong></td><td>[2 min read]</td><td>A summary of how to write tests using Cover CLI.</td><td></td><td></td><td><a href="/pages/jJZ7S2eFGuIm8lUnxxHl">/pages/jJZ7S2eFGuIm8lUnxxHl</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Command Summary</strong></td><td>[2 min read]</td><td>A summary of the core Cover CLI commands and arguments.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/w8H2hQw4tN8jPrx30Q8M">/pages/w8H2hQw4tN8jPrx30Q8M</a></td></tr><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Cover CLI Overview</strong></td><td>[29 min watch]</td><td>Get a complete overview of Cover CLI with this tutorial video.</td><td></td><td></td><td><a href="https://youtu.be/LPHw0JNcMyw">https://youtu.be/LPHw0JNcMyw</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Commands &#x26; Arguments</strong></td><td>[reference]</td><td>Reference topic - details of all available commands and arguments.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/ZyGf7PJtCwoAYAMjWuOL">/pages/ZyGf7PJtCwoAYAMjWuOL</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Test Examples</strong></td><td>[5 min read]</td><td>Unit test examples of varying complexity.</td><td></td><td></td><td><a href="/pages/9qeCqYtwbx0JZsPjYC55">/pages/9qeCqYtwbx0JZsPjYC55</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Project Configuration &#x26; Dependencies</strong></td><td>[9 topics]</td><td>Making sure your project configuration and dependencies meet the requirements needed to use Diffblue Cover.</td><td></td><td></td><td><a href="/pages/QvkFNVEoZtRq5c7MJCxJ">/pages/QvkFNVEoZtRq5c7MJCxJ</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Preflight Checks</strong></td><td>[5 min read]</td><td>Diffblue Cover's preflight features for checking the suitability of your environment.</td><td></td><td></td><td><a href="/pages/6NrsjMICKX4GuFDqhTrI">/pages/6NrsjMICKX4GuFDqhTrI</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Output Codes</strong></td><td>[5 reference topics]</td><td>Reference details - Diffblue Cover output codes, messages, and descriptions.</td><td></td><td></td><td><a href="/pages/NesTdPaeLWtiOqUPTgND">/pages/NesTdPaeLWtiOqUPTgND</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Specs &#x26; Reqs</strong></td><td>[reference topic]</td><td>Reference details - Diffblue Cover specifications and requirements.</td><td></td><td></td><td><a href="/pages/pDoeGe6cmbIF025UbKoh">/pages/pDoeGe6cmbIF025UbKoh</a></td></tr></tbody></table>

## Know more...

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Output Codes</strong></td><td>[5 reference topics]</td><td>Reference details - Diffblue Cover output codes, messages, and descriptions.</td><td></td><td></td><td><a href="/pages/NesTdPaeLWtiOqUPTgND">/pages/NesTdPaeLWtiOqUPTgND</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Working With Output Codes</strong></td><td>[12 topics]</td><td>Useful hints and tips to help resolve a range of output codes.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/Kjj38nxdpW3Yo9eupAaH">/pages/Kjj38nxdpW3Yo9eupAaH</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Partial Tests</strong></td><td>[4 min read]</td><td>Creating partial (incomplete) tests.</td><td></td><td></td><td><a href="/pages/oD2BfM4T9zVatAA63jZo">/pages/oD2BfM4T9zVatAA63jZo</a></td></tr><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Custom Inputs</strong></td><td>[22 min watch]</td><td>Demonstrating how to provide custom inputs to optimize test creation.</td><td><strong>Title</strong></td><td></td><td><a href="https://youtu.be/1xRWbErG92c">https://youtu.be/1xRWbErG92c</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Custom Inputs</strong></td><td>[12 min read]</td><td>Provide custom inputs to optimize test creation.</td><td></td><td></td><td><a href="/pages/W7U31Unw4oyS26QCdiyc">/pages/W7U31Unw4oyS26QCdiyc</a></td></tr><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Custom Test Setup</strong></td><td>[31 min watch]</td><td>Demonstrating how to provide a custom base class to optimize test creation.</td><td></td><td></td><td><a href="https://youtu.be/TJnx2xPlL_4">https://youtu.be/TJnx2xPlL_4</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Custom Test Setup</strong></td><td>[6 min read]</td><td>Provide a custom base class to optimize test creation.</td><td></td><td></td><td><a href="/pages/QABQe0nh3ds29e8B9N5S">/pages/QABQe0nh3ds29e8B9N5S</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Test Naming</strong></td><td>[4 min read]</td><td>Test naming config and defaults.</td><td></td><td></td><td><a href="/pages/oQUzj4EukaB1zLe1W1QR">/pages/oQUzj4EukaB1zLe1W1QR</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Test Formatting</strong></td><td>[4 min read]</td><td>Configure the format of tests written by Cover CLI.</td><td></td><td></td><td><a href="/pages/5O8MomX9oDsV6U2CEskT">/pages/5O8MomX9oDsV6U2CEskT</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Test Insertion Order</strong></td><td>[2 min read]</td><td>Test method ordering in test classes.</td><td></td><td></td><td><a href="/pages/o5G1eaV46wHdd4vp4CDv">/pages/o5G1eaV46wHdd4vp4CDv</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Refactor</strong></td><td>[4 min read]</td><td>Use Cover Refactor to automatically suggest and apply refactorings to your code to help improve test coverage.</td><td></td><td></td><td><a href="/pages/RR2PuATAT82g3V0HNteJ">/pages/RR2PuATAT82g3V0HNteJ</a></td></tr></tbody></table>

## Next steps...

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Cover CLI Admin</strong></td><td>Manage and maintain Cover CLI.</td><td></td><td></td><td><a href="/pages/jHRORHbkETxJS10mLbcT">/pages/jHRORHbkETxJS10mLbcT</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Test Coverage</strong></td><td>Improve and manage test coverage.</td><td></td><td></td><td><a href="/pages/hiaZKocqUOo7clxq7Vj8">/pages/hiaZKocqUOo7clxq7Vj8</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Tutorials</strong></td><td>A range of tutorials covering topics such as implementing a code change and working with Kotlin projects.</td><td></td><td></td><td><a href="/pages/QRCujrjPS1ZqlXeapQTO">/pages/QRCujrjPS1ZqlXeapQTO</a></td></tr></tbody></table>


# Test coverage

Create coverage reports and improve test coverage. This learning path is targeted at developers - see the [Test Coverage](/get-started/diffblue-learning/test-coverage) group for all coverage related learning paths.

{% hint style="info" %}
Before starting this learning path, we recommend that you first complete the [Cover CLI Get Started](/get-started/diffblue-learning/get-started/cover-cli-command-line) path or the [Cover Plugin Get Started](/get-started/diffblue-learning/get-started/cover-plugin-ide) path.
{% endhint %}

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Improving Coverage</strong></td><td>[4 min read]</td><td>This tutorial provides general information on improving your test coverage.</td><td></td><td></td><td><a href="/pages/6i5bgxJLrSVm7AMrvNxw">/pages/6i5bgxJLrSVm7AMrvNxw</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Output Codes</strong></td><td>[5 reference topics]</td><td>Reference details - Diffblue Cover output codes, messages, and descriptions.</td><td></td><td></td><td><a href="/pages/NesTdPaeLWtiOqUPTgND">/pages/NesTdPaeLWtiOqUPTgND</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Working With Output Codes</strong></td><td>[12 topics]</td><td>Useful hints and tips to help resolve a range of output codes.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/Kjj38nxdpW3Yo9eupAaH">/pages/Kjj38nxdpW3Yo9eupAaH</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Refactor</strong></td><td>[4 min read]</td><td>Use Cover Refactor to automatically suggest and apply refactorings to your code to help improve test coverage.</td><td></td><td></td><td><a href="/pages/RR2PuATAT82g3V0HNteJ">/pages/RR2PuATAT82g3V0HNteJ</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Reports Intro</strong></td><td>[3 min read]</td><td>An introduction and overview of Cover Reports.</td><td></td><td></td><td><a href="/pages/9oHmWHdRWPnO6scWUlTO">/pages/9oHmWHdRWPnO6scWUlTO</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Generate &#x26; Upload Reports Bundles</strong></td><td>[8 min read]</td><td>Specifically for Cover Reports Contributors (Developers) - how to generate and upload reports bundles using Cover CLI.</td><td></td><td></td><td><a href="/pages/i4X8VWfSDPRTzO79yHTz">/pages/i4X8VWfSDPRTzO79yHTz</a></td></tr></tbody></table>


# DevOps

Detailed learning paths targeted at DevOps:

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>GitHub</strong></td><td>Integrate the Diffblue Cover Action into your GitHub workflows.</td><td></td><td><a href="/pages/2jZ20nXnaKa3Q8yVOxti">/pages/2jZ20nXnaKa3Q8yVOxti</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>GitLab</strong></td><td>Incorporate the Diffblue Cover Project Integration into your GitLab pipeline.</td><td></td><td><a href="/pages/q8fInfSpZjKxkcElqoU4">/pages/q8fInfSpZjKxkcElqoU4</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Other CI</strong></td><td>Integrate Cover CLI into your CI pipeline workflow - Jenkins, Azure, AWS.</td><td></td><td><a href="/pages/NBBIl5WiV6njbOfNk5Pp">/pages/NBBIl5WiV6njbOfNk5Pp</a></td></tr></tbody></table>

#### Achievements:

* [x] Understand the use of Diffblue Cover within a CI/CD environment.
* [x] Know how to activate and configure Cover Pipeline within your chosen CI/CD tool - initial setup and additional config options.
* [x] Know how to use Cover Pipeline to write tests for your projects - basic and advanced concepts.


# GitHub

Integrate Diffblue Cover into your GitHub Actions workflows - Cover Pipeline for GitHub.

## Start here...

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>What is Diffblue Cover</strong></td><td>[8 min read]</td><td>An introduction and overview of Diffblue Cover including features, benefits, and how it works.</td><td></td><td></td><td><a href="/pages/JuNKt6UxiiRtm5c1hF39">/pages/JuNKt6UxiiRtm5c1hF39</a></td></tr><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Introducing Cover Pipeline for GitHub</strong></td><td>[3 min watch]</td><td>An overview of Cover Pipeline for GitHub and a brief demonstration of how to activate, configure, and use Diffblue Cover directly within your GitHub Actions workflows.</td><td></td><td></td><td><a href="https://youtu.be/blxHRCYD1kA">https://youtu.be/blxHRCYD1kA</a></td></tr><tr><td><img src="/files/GMxVix3Kxsh9Ca9DIxN9" alt="" data-size="original"> <strong>Free Trial Registration</strong></td><td>[1 min sign-up]</td><td>If you haven't signed up for the Cover Pipeline for GitHub trial yet, use this link to provide your details and get your license code.</td><td><strong>Title</strong></td><td></td><td><a href="https://www.diffblue.com/try-cover/github/">https://www.diffblue.com/try-cover/github/</a></td></tr><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Getting Started Video</strong></td><td>[4 min watch]</td><td>A full demonstration of how to activate, configure, and use Diffblue Cover directly within your GitHub Actions workflows.</td><td><strong>Title</strong></td><td></td><td><a href="https://youtu.be/KRw47RBt3Gw">https://youtu.be/KRw47RBt3Gw</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Getting Started Docs</strong></td><td>[6 min read]</td><td>Step-by-step details of how to activate, configure, and use Diffblue Cover directly within your GitHub Actions workflows.</td><td></td><td></td><td><a href="/pages/MsHHkFkNFsRKefZz6HFz">/pages/MsHHkFkNFsRKefZz6HFz</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>GitHub Workflow</strong></td><td>[3 min read]</td><td>Illustrative development workflows, with and without Cover Pipeline for GitHub.</td><td></td><td></td><td><a href="/pages/VqXXIH27x60sSlcVyrEG">/pages/VqXXIH27x60sSlcVyrEG</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>GitHub Config</strong></td><td>[6 min read]</td><td>Configuration options including labels, environment config, and workflow config.</td><td></td><td></td><td><a href="/pages/m9qj9BcqF56sJ1yMzPlE">/pages/m9qj9BcqF56sJ1yMzPlE</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Specs &#x26; Reqs</strong></td><td>[reference topic]</td><td>Reference details - Diffblue Cover specifications and requirements.</td><td></td><td></td><td><a href="/pages/pDoeGe6cmbIF025UbKoh">/pages/pDoeGe6cmbIF025UbKoh</a></td></tr></tbody></table>

## Alternatives...

Diffblue Cover CI/CD integrations using alternative CI tools:

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>GitLab</strong></td><td>Incorporate the Diffblue Cover Project Integration into your GitLab pipeline.</td><td></td><td><a href="/pages/q8fInfSpZjKxkcElqoU4">/pages/q8fInfSpZjKxkcElqoU4</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Other CI</strong></td><td>Integrate Cover CLI into your CI pipeline workflow - Jenkins, Azure, AWS.</td><td></td><td><a href="/pages/NBBIl5WiV6njbOfNk5Pp">/pages/NBBIl5WiV6njbOfNk5Pp</a></td></tr></tbody></table>

## Next steps...

Learn about Diffblue's developer tools:

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Get Started Video - IDE Only</strong></td><td>[5 min watch]</td><td>A demonstration of how to download, install, license, and use Cover Plugin to write tests for a sample project.</td><td><strong>Title</strong></td><td></td><td><a href="https://youtu.be/wQ-W8Q5FYBU">https://youtu.be/wQ-W8Q5FYBU</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Get Started Docs - IDE Only</strong></td><td>[8 min read]</td><td>Step-by-step details of how to download, install, license, and use Cover Plugin to write tests for a sample project.</td><td></td><td></td><td><a href="/pages/Ios2MK7nZhRtOElluf0u">/pages/Ios2MK7nZhRtOElluf0u</a></td></tr><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Get Started Video - CLI Only</strong></td><td>[7 min watch]</td><td>A demonstration of how to download, install, license, and use Cover CLI to write tests for a sample project.</td><td></td><td></td><td><a href="https://youtu.be/eZkDQsYM9fA">https://youtu.be/eZkDQsYM9fA</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Get Started Docs - CLI Only</strong></td><td>[8 min read]</td><td>Step-by-step details of how to download, install, license, and use Cover CLI to write tests for a sample project.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/7V85GXh1MOFovvH55h1E">/pages/7V85GXh1MOFovvH55h1E</a></td></tr></tbody></table>


# GitLab

Integrate Diffblue Cover into your GitLab pipeline - Cover Pipeline for GitLab.

## Start here...

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>What is Diffblue Cover</strong></td><td>[8 min read]</td><td>An introduction and overview of Diffblue Cover including features, benefits, and how it works.</td><td></td><td></td><td><a href="/pages/JuNKt6UxiiRtm5c1hF39">/pages/JuNKt6UxiiRtm5c1hF39</a></td></tr><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Introducing Cover Pipeline for GitLab</strong></td><td>[4 min watch]</td><td>An overview of Cover Pipeline for GitLab and a brief demonstration of how to install, activate, and use Diffblue Cover directly within your GitLab pipeline.</td><td></td><td></td><td><a href="https://youtu.be/7UBOTJzjF1E">https://youtu.be/7UBOTJzjF1E</a></td></tr><tr><td><img src="/files/GMxVix3Kxsh9Ca9DIxN9" alt="" data-size="original"> <strong>Free Trial Registration</strong></td><td>[1 min sign-up]</td><td>If you haven't signed up for the Cover Pipeline for GitLab trial yet, use this link to provide your details and get your license code.</td><td><strong>Title</strong></td><td></td><td><a href="https://www.diffblue.com/try-cover/gitlab/">https://www.diffblue.com/try-cover/gitlab/</a></td></tr><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Getting Started</strong></td><td>[6 min watch]</td><td>A full demonstration of how to install, activate, configure, and use Diffblue Cover directly within your GitLab pipeline.</td><td><strong>Title</strong></td><td></td><td><a href="https://youtu.be/SoqH6AUuqow">https://youtu.be/SoqH6AUuqow</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Getting Started</strong></td><td>[6 min read]</td><td>Step-by-step details of how to install, activate, configure, and use Diffblue Cover directly within your GitLab pipeline.</td><td></td><td></td><td><a href="/pages/XaNY0jUxBiJnTaDxNgM7">/pages/XaNY0jUxBiJnTaDxNgM7</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>GitLab Workflow</strong></td><td>[3 min read]</td><td>Illustrative development workflows, with and without Cover Pipeline for GitLab.</td><td></td><td></td><td><a href="/pages/PXOnduvYWF2UjmbFBrSX">/pages/PXOnduvYWF2UjmbFBrSX</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>GitLab Config</strong></td><td>[6 min read]</td><td>Configuration options including labels, environment config, and workflow config.</td><td></td><td></td><td><a href="/pages/RCxy5gZEYKZ2ng93HDvs">/pages/RCxy5gZEYKZ2ng93HDvs</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Specs &#x26; Reqs</strong></td><td>[reference topic]</td><td>Reference details - Diffblue Cover specifications and requirements.</td><td></td><td></td><td><a href="/pages/pDoeGe6cmbIF025UbKoh">/pages/pDoeGe6cmbIF025UbKoh</a></td></tr></tbody></table>

## Alternatives...

Diffblue Cover CI/CD integrations using alternative CI tools:

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>GitHub</strong></td><td>Incorporate the Diffblue Cover Action into your GitHub workflow.</td><td></td><td><a href="/pages/2jZ20nXnaKa3Q8yVOxti">/pages/2jZ20nXnaKa3Q8yVOxti</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Other CI</strong></td><td>Integrate Cover CLI into your CI pipeline workflow - Jenkins, Azure, AWS.</td><td></td><td><a href="/pages/NBBIl5WiV6njbOfNk5Pp">/pages/NBBIl5WiV6njbOfNk5Pp</a></td></tr></tbody></table>

## Next steps...

Learn about Diffblue's developer tools:

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Get Started Video - IDE Only</strong></td><td>[5 min watch]</td><td>A demonstration of how to download, install, license, and use Cover Plugin to write tests for a sample project.</td><td><strong>Title</strong></td><td></td><td><a href="https://youtu.be/wQ-W8Q5FYBU">https://youtu.be/wQ-W8Q5FYBU</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Get Started Docs - IDE Only</strong></td><td>[8 min read]</td><td>Step-by-step details of how to download, install, license, and use Cover Plugin to write tests for a sample project.</td><td></td><td></td><td><a href="/pages/Ios2MK7nZhRtOElluf0u">/pages/Ios2MK7nZhRtOElluf0u</a></td></tr><tr><td><img src="/files/8yHqv1wJhhp1C1tWe9M7" alt="" data-size="original"> <strong>Get Started Video - CLI Only</strong></td><td>[7 min watch]</td><td>A demonstration of how to download, install, license, and use Cover CLI to write tests for a sample project.</td><td></td><td></td><td><a href="https://youtu.be/eZkDQsYM9fA">https://youtu.be/eZkDQsYM9fA</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Get Started Docs - CLI Only</strong></td><td>[8 min read]</td><td>Step-by-step details of how to download, install, license, and use Cover CLI to write tests for a sample project.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/7V85GXh1MOFovvH55h1E">/pages/7V85GXh1MOFovvH55h1E</a></td></tr></tbody></table>


# Other CI

Integrate Cover CLI into your CI pipeline workflow - Jenkins, Azure, AWS.

## Start here...

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>What is Diffblue Cover</strong></td><td>[8 min read]</td><td>An introduction and overview of Diffblue Cover including features, benefits, and how it works.</td><td></td><td></td><td><a href="/pages/JuNKt6UxiiRtm5c1hF39">/pages/JuNKt6UxiiRtm5c1hF39</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Cover Pipeline for CI</strong></td><td>[3 min read]</td><td>An overview of the options and features available when integrating Diffblue Cover into a CI pipeline.</td><td></td><td></td><td><a href="/pages/GurEbfPf3yVx75QCornF">/pages/GurEbfPf3yVx75QCornF</a></td></tr><tr><td><img src="/files/GMxVix3Kxsh9Ca9DIxN9" alt="" data-size="original"> <strong>Free Trial Registration</strong></td><td>[1 min sign-up]</td><td>If you haven't signed up for the Diffblue Cover trial yet, use this link to provide your details and get your license code.</td><td><strong>Title</strong></td><td></td><td><a href="https://www.diffblue.com/try-cover/">https://www.diffblue.com/try-cover/</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Quick Start - General</strong></td><td>[6 min read]</td><td>General getting started guidance, applicable to most CI/CD tools.</td><td></td><td></td><td><a href="/pages/Qw4XoMd7zMkHZynDnhVP">/pages/Qw4XoMd7zMkHZynDnhVP</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Quick Start - Jenkins</strong></td><td>[6 min read]</td><td>General getting started guidance, applicable to Jenkins.</td><td></td><td></td><td><a href="/pages/qOa3Qgg5heo6CVGlPrzR">/pages/qOa3Qgg5heo6CVGlPrzR</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Quick Start - Azure</strong></td><td>[6 min read]</td><td>General getting started guidance, applicable to Azure.</td><td></td><td></td><td><a href="/pages/wPRQtaCFk1C7AJlzeYlZ">/pages/wPRQtaCFk1C7AJlzeYlZ</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Quick Start - AWS</strong></td><td>[6 min read]</td><td>General getting started guidance, applicable to AWS.</td><td></td><td></td><td><a href="/pages/UFXPhb1gNeT7yPukRjHD">/pages/UFXPhb1gNeT7yPukRjHD</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Specs &#x26; Reqs</strong></td><td>[reference topic]</td><td>Reference details - Diffblue Cover specifications and requirements.</td><td></td><td></td><td><a href="/pages/pDoeGe6cmbIF025UbKoh">/pages/pDoeGe6cmbIF025UbKoh</a></td></tr></tbody></table>

## Alternatives...

Diffblue Cover CI/CD integrations using alternative CI tools:

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>GitHub</strong></td><td>Integrate the Diffblue Cover Action into your GitHub workflows.</td><td></td><td><a href="/pages/2jZ20nXnaKa3Q8yVOxti">/pages/2jZ20nXnaKa3Q8yVOxti</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>GitLab</strong></td><td>Incorporate the Diffblue Cover Project Integration into your GitLab pipeline.</td><td></td><td><a href="/pages/q8fInfSpZjKxkcElqoU4">/pages/q8fInfSpZjKxkcElqoU4</a></td></tr></tbody></table>

## Next steps...

Learn about the additional tools provided with Cover Pipeline:

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Get Started - Cover Plugin</strong></td><td>[8 min read]</td><td>Download, install, license, and use Cover CLI to write tests for a sample project.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/7V85GXh1MOFovvH55h1E">/pages/7V85GXh1MOFovvH55h1E</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Get Started - Cover CLI</strong></td><td>[8 min read]</td><td>Download, install, license, and use Cover Plugin to write tests for a sample project.</td><td></td><td></td><td><a href="/pages/Ios2MK7nZhRtOElluf0u">/pages/Ios2MK7nZhRtOElluf0u</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Get Started - Cover Optimize</strong></td><td>[3 min read]</td><td>Speed up the time required to run Java unit tests by only running the tests related to a code change.</td><td></td><td></td><td><a href="/pages/KwbiHMD34DNxrv0bYx7h">/pages/KwbiHMD34DNxrv0bYx7h</a></td></tr></tbody></table>


# Administrator

Detailed learning paths targeted at "administrators" - manage and maintain Diffblue Cover for you, or your organization:

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Admin - IntelliJ</strong></td><td>Install, manage, and maintain Cover Plugin.</td><td></td><td><a href="/pages/wg5tzP7mPb3gHcZdfyF3">/pages/wg5tzP7mPb3gHcZdfyF3</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Admin - CLI</strong></td><td>Install, manage, and maintain Cover CLI.</td><td></td><td><a href="/pages/jHRORHbkETxJS10mLbcT">/pages/jHRORHbkETxJS10mLbcT</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Admin - Reports</strong></td><td>Install, manage, and maintain Cover Reports.</td><td></td><td><a href="/pages/ne2tVHESFos3ifm12mhl">/pages/ne2tVHESFos3ifm12mhl</a></td></tr></tbody></table>

#### Achievements:

* [x] Understand how to install, update, manage, and maintain Diffblue Cover, including config options and license management.


# Admin - IntelliJ

Manage and maintain Cover Plugin for yourself or your organization.

{% hint style="info" %}
Before starting this learning path, we recommend that you first complete the [Cover Plugin Get Started](/get-started/diffblue-learning/get-started/cover-plugin-ide) path and (optionally) the [IDE Unit Tests](/get-started/diffblue-learning/developer/unit-tests-ide) path.
{% endhint %}

## Start here...

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Core Maintenance</strong></td><td>[5 min read]</td><td>Install, update, disable, enable, uninstall.</td><td></td><td></td><td><a href="/pages/EB2TKFe8mPLHo1jKKzHo">/pages/EB2TKFe8mPLHo1jKKzHo</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>What's New</strong></td><td>[reference topic]</td><td>Summary and details of the latest Diffblue Cover updates and enhancements.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/y3sCtpfoHXUrOOqmBuxW">/pages/y3sCtpfoHXUrOOqmBuxW</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Licensing</strong></td><td>[3 min read]</td><td>A summary of the Diffblue licensing options.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/66tpWR5RYATs6ph8klrg">/pages/66tpWR5RYATs6ph8klrg</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Settings</strong></td><td>[3 min read]</td><td>A summary of available Cover Plugin settings.</td><td></td><td></td><td><a href="/pages/EdoIpG8mg32SMjN2Unrn">/pages/EdoIpG8mg32SMjN2Unrn</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Telemetry</strong></td><td>[3 min read]</td><td>Enable/disable and configure telemetry for Cover Plugin.</td><td></td><td></td><td><a href="/pages/Pd0XkXikcB9bsohu0ddo">/pages/Pd0XkXikcB9bsohu0ddo</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Memory Management</strong></td><td>[3 min read]</td><td>Tips for memory management.</td><td></td><td></td><td><a href="/pages/y7X58s3xvVkH1V3edwFi">/pages/y7X58s3xvVkH1V3edwFi</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Log Files</strong></td><td>[3 min read]</td><td>User and Support log files.</td><td></td><td></td><td><a href="/pages/1iCAp5IPK1ieue8Cv5Nk">/pages/1iCAp5IPK1ieue8Cv5Nk</a></td></tr></tbody></table>

## Next steps...

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Test Coverage</strong></td><td>Improve and manage test coverage.</td><td></td><td></td><td><a href="/pages/aczpC6h6qptNxPn5HBcx">/pages/aczpC6h6qptNxPn5HBcx</a></td></tr><tr><td><img src="/files/GMxVix3Kxsh9Ca9DIxN9" alt="" data-size="original"> <strong>Support</strong></td><td>Where to get support for Diffblue Cover.</td><td></td><td></td><td><a href="https://www.diffblue.com/support/">https://www.diffblue.com/support/</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Tutorials</strong></td><td>A range of tutorials covering topics such as implementing a code change and working with Kotlin projects.</td><td></td><td></td><td><a href="/pages/QRCujrjPS1ZqlXeapQTO">/pages/QRCujrjPS1ZqlXeapQTO</a></td></tr></tbody></table>


# Admin - CLI

Manage and maintain Cover CLI for yourself or your organization.

{% hint style="info" %}
Before starting this learning path, we recommend that you first complete the [Cover CLI Get Started](/get-started/diffblue-learning/get-started/cover-cli-command-line) path and (optionally) the [CLI Unit Tests](/get-started/diffblue-learning/developer/unit-tests-cli) path.
{% endhint %}

## Start here...

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Core Maintenance</strong></td><td>[5 min read]</td><td>Install or update Cover CLI.</td><td></td><td></td><td><a href="/pages/o2kyMrQ2n93rwvr5Brrt">/pages/o2kyMrQ2n93rwvr5Brrt</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>What's New</strong></td><td>[reference topic]</td><td>Summary and details of the latest Diffblue Cover updates and enhancements.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/y3sCtpfoHXUrOOqmBuxW">/pages/y3sCtpfoHXUrOOqmBuxW</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Licensing</strong></td><td>[3 min read]</td><td>A summary of the Diffblue licensing options.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/66tpWR5RYATs6ph8klrg">/pages/66tpWR5RYATs6ph8klrg</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Telemetry</strong></td><td>[3 min read]</td><td>Enable/disable and configure telemetry for Cover CLI.</td><td></td><td></td><td><a href="/pages/PoRfYDVqIBeGE1SzVY2o">/pages/PoRfYDVqIBeGE1SzVY2o</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Memory Management</strong></td><td>[3 min read]</td><td>Tips for memory management.</td><td></td><td></td><td><a href="/pages/otiDY1qA007N5EebQtWZ">/pages/otiDY1qA007N5EebQtWZ</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Log Files</strong></td><td>[3 min read]</td><td>User and Support log files.</td><td></td><td></td><td><a href="/pages/2lUwlmEfnB7XpmviO3B2">/pages/2lUwlmEfnB7XpmviO3B2</a></td></tr></tbody></table>

## Next steps...

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Test Coverage</strong></td><td>Improve and manage test coverage.</td><td></td><td></td><td><a href="/pages/aczpC6h6qptNxPn5HBcx">/pages/aczpC6h6qptNxPn5HBcx</a></td></tr><tr><td><img src="/files/GMxVix3Kxsh9Ca9DIxN9" alt="" data-size="original"> <strong>Support</strong></td><td>Where to get support for Diffblue Cover.</td><td></td><td></td><td><a href="https://www.diffblue.com/support/">https://www.diffblue.com/support/</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Tutorials</strong></td><td>A range of tutorials covering topics such as implementing a code change and working with Kotlin projects.</td><td></td><td></td><td><a href="/pages/QRCujrjPS1ZqlXeapQTO">/pages/QRCujrjPS1ZqlXeapQTO</a></td></tr></tbody></table>


# Admin - Reports

Manage and maintain your Cover Reports instance.

## Start here...

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Cover Reports Intro</strong></td><td>[2 min read]</td><td>A brief introduction to Cover Reports.</td><td></td><td></td><td><a href="/pages/9oHmWHdRWPnO6scWUlTO">/pages/9oHmWHdRWPnO6scWUlTO</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Install &#x26; Update</strong></td><td>[6 min read]</td><td>Install and update Cover Reports.</td><td></td><td></td><td><a href="/pages/8qHakpMc2QI3cbWMr5kA">/pages/8qHakpMc2QI3cbWMr5kA</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Configuration Options</strong></td><td>[8 min read]</td><td>Details of available configuration options.</td><td></td><td></td><td><a href="/pages/Fn5ONftzxaats7f5qnv6">/pages/Fn5ONftzxaats7f5qnv6</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Database Backup</strong></td><td>[4 min read]</td><td>Backup details for the for the default H2 database or optional (production grade environment) PostgreSQL database.</td><td></td><td></td><td><a href="/pages/7eZMPStLw0uT7iOSL7FZ">/pages/7eZMPStLw0uT7iOSL7FZ</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>SSO</strong></td><td>[5 min read]</td><td>SSO prerequisites and considerations, plus NGINX setup guide links.</td><td></td><td></td><td><a href="/pages/dhEnrTvlaEm1qG3nl37o">/pages/dhEnrTvlaEm1qG3nl37o</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Uninstall</strong></td><td>[3 min read]</td><td>Uninstall details.</td><td></td><td></td><td><a href="/pages/ZGbGtNxi2bUmkB5Kqabb">/pages/ZGbGtNxi2bUmkB5Kqabb</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>What's New</strong></td><td>[reference topic]</td><td>Summary and details of the latest Diffblue Cover updates and enhancements.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/H9LZtPMiJPWmU92BMWFN">/pages/H9LZtPMiJPWmU92BMWFN</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Licensing</strong></td><td>[3 min read]</td><td>A summary of the Diffblue licensing options.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/Dti3AM5yb7IYXls9Atm6">/pages/Dti3AM5yb7IYXls9Atm6</a></td></tr></tbody></table>

## Next steps...

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Cover Reports UI</strong></td><td>Using Cover Reports.</td><td></td><td></td><td><a href="/pages/rfDBiTpAt2yreWHjEjBD">/pages/rfDBiTpAt2yreWHjEjBD</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Test Coverage</strong></td><td>Improve and manage test coverage.</td><td></td><td></td><td><a href="/pages/aczpC6h6qptNxPn5HBcx">/pages/aczpC6h6qptNxPn5HBcx</a></td></tr><tr><td><img src="/files/GMxVix3Kxsh9Ca9DIxN9" alt="" data-size="original"> <strong>Support</strong></td><td>Where to get support for Diffblue Cover.</td><td></td><td></td><td><a href="https://www.diffblue.com/support/">https://www.diffblue.com/support/</a></td></tr></tbody></table>


# Test coverage

Improve, monitor, and manage your test coverage:

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Developer</strong></td><td>Generate and upload Cover Reports bundles.</td><td></td><td><a href="/pages/9PDxCPRetrOBD85McUrS">/pages/9PDxCPRetrOBD85McUrS</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Senior Developer</strong></td><td>Use Cover Reports to monitor and manage test coverage.</td><td></td><td><a href="/pages/JyZmXGYsLr8FP6gfR7xA">/pages/JyZmXGYsLr8FP6gfR7xA</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Administrator</strong></td><td>Manage and maintain your Cover Reports instance.</td><td></td><td><a href="/pages/gIedWMkiEPbbN9yivkMz">/pages/gIedWMkiEPbbN9yivkMz</a></td></tr></tbody></table>

#### Achievements:

* [x] Know how to improve, monitor, and manage your test coverage.
* [x] Know how to improve test coverage for your code base, including automated refactoring.
* [x] Understand output codes and how to resolve them.
* [x] Understand how to use Cover Reports to monitor and manage test coverage.
* [x] Know how to manage your Cover Reports instance including installation, database backups, and software updates.


# Developer

Create coverage reports and improve test coverage. This learning path is targeted at developers - see the [Senior Developer](/get-started/diffblue-learning/test-coverage/senior-developer) learning path for details of coverage monitoring and maintenance.

{% hint style="info" %}
Before starting this learning path, we recommend that you first complete the [Cover CLI Get Started](/get-started/diffblue-learning/get-started/cover-cli-command-line) path and the [CLI Unit Tests](/get-started/diffblue-learning/developer/unit-tests-cli) path.
{% endhint %}

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Improving Coverage</strong></td><td>[4 min read]</td><td>This tutorial provides general information on improving your test coverage.</td><td></td><td></td><td><a href="/pages/6i5bgxJLrSVm7AMrvNxw">/pages/6i5bgxJLrSVm7AMrvNxw</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Output Codes</strong></td><td>[5 reference topics]</td><td>Reference details - Diffblue Cover output codes, messages, and descriptions.</td><td></td><td></td><td><a href="/pages/NesTdPaeLWtiOqUPTgND">/pages/NesTdPaeLWtiOqUPTgND</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Working With Output Codes</strong></td><td>[12 topics]</td><td>Useful hints and tips to help resolve a range of output codes.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/Kjj38nxdpW3Yo9eupAaH">/pages/Kjj38nxdpW3Yo9eupAaH</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Refactor</strong></td><td>[4 min read]</td><td>Use Cover Refactor to automatically suggest and apply refactorings to your code to help improve test coverage.</td><td></td><td></td><td><a href="/pages/RR2PuATAT82g3V0HNteJ">/pages/RR2PuATAT82g3V0HNteJ</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Reports Intro</strong></td><td>[3 min read]</td><td>An introduction and overview of Cover Reports.</td><td></td><td></td><td><a href="/pages/9oHmWHdRWPnO6scWUlTO">/pages/9oHmWHdRWPnO6scWUlTO</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Generate &#x26; Upload Reports Bundles</strong></td><td>[8 min read]</td><td>Specifically for Cover Reports Contributors (Developers) - how to generate and upload reports bundles using Cover CLI.</td><td></td><td></td><td><a href="/pages/i4X8VWfSDPRTzO79yHTz">/pages/i4X8VWfSDPRTzO79yHTz</a></td></tr></tbody></table>


# Senior developer

Use Cover Reports to monitor and manage test coverage.

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Cover Reports Intro</strong></td><td>[2 min read]</td><td>A brief introduction to Cover Reports.</td><td></td><td></td><td><a href="/pages/9oHmWHdRWPnO6scWUlTO">/pages/9oHmWHdRWPnO6scWUlTO</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Dashboards</strong></td><td>[5 min read]</td><td>Coverage data and visualizations available through each of the dashboards/tabs.</td><td></td><td></td><td><a href="/pages/armuWasyLj61PvXt6KpX">/pages/armuWasyLj61PvXt6KpX</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Telemetry</strong></td><td>[3 min read]</td><td>Monitor Diffblue Cover usage across your organization.</td><td></td><td></td><td><a href="/pages/TXYusJuulPglqWD7Qia3">/pages/TXYusJuulPglqWD7Qia3</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Considerations</strong></td><td>[3 min read]</td><td>A few considerations for managing your coverage data and Cover Reports deployment.</td><td></td><td></td><td><a href="/pages/UkbOYxKmhoEVjejFAYHK">/pages/UkbOYxKmhoEVjejFAYHK</a></td></tr></tbody></table>


# Cover Reports Administrator

Manage and maintain your Cover Reports instance.

## Start here...

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Cover Reports Intro</strong></td><td>[2 min read]</td><td>A brief introduction to Cover Reports.</td><td></td><td></td><td><a href="/pages/9oHmWHdRWPnO6scWUlTO">/pages/9oHmWHdRWPnO6scWUlTO</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Install &#x26; Update</strong></td><td>[6 min read]</td><td>Install and update Cover Reports.</td><td></td><td></td><td><a href="/pages/8qHakpMc2QI3cbWMr5kA">/pages/8qHakpMc2QI3cbWMr5kA</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Configuration Options</strong></td><td>[8 min read]</td><td>Details of available configuration options.</td><td></td><td></td><td><a href="/pages/Fn5ONftzxaats7f5qnv6">/pages/Fn5ONftzxaats7f5qnv6</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Database Backup</strong></td><td>[4 min read]</td><td>Backup details for the for the default H2 database or optional (production grade environment) PostgreSQL database.</td><td></td><td></td><td><a href="/pages/7eZMPStLw0uT7iOSL7FZ">/pages/7eZMPStLw0uT7iOSL7FZ</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>SSO</strong></td><td>[5 min read]</td><td>SSO prerequisites and considerations, plus NGINX setup guide links.</td><td></td><td></td><td><a href="/pages/dhEnrTvlaEm1qG3nl37o">/pages/dhEnrTvlaEm1qG3nl37o</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Uninstall</strong></td><td>[3 min read]</td><td>Uninstall details.</td><td></td><td></td><td><a href="/pages/ZGbGtNxi2bUmkB5Kqabb">/pages/ZGbGtNxi2bUmkB5Kqabb</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>What's New</strong></td><td>[reference topic]</td><td>Summary and details of the latest Diffblue Cover updates and enhancements.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/y3sCtpfoHXUrOOqmBuxW">/pages/y3sCtpfoHXUrOOqmBuxW</a></td></tr><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Licensing</strong></td><td>[3 min read]</td><td>A summary of the Diffblue licensing options.</td><td><strong>Title</strong></td><td></td><td><a href="/pages/66tpWR5RYATs6ph8klrg">/pages/66tpWR5RYATs6ph8klrg</a></td></tr></tbody></table>

## Next steps...

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="/files/wLFcMHFyk956RgsZ8klA" alt="" data-size="original"> <strong>Cover Reports UI</strong></td><td>Using Cover Reports.</td><td></td><td></td><td><a href="/pages/rfDBiTpAt2yreWHjEjBD">/pages/rfDBiTpAt2yreWHjEjBD</a></td></tr><tr><td><img src="/files/YTAmGIL0J9z35xc4ToLw" alt="" data-size="original"> <strong>Test Coverage</strong></td><td>Improve and manage test coverage.</td><td></td><td></td><td><a href="/pages/aczpC6h6qptNxPn5HBcx">/pages/aczpC6h6qptNxPn5HBcx</a></td></tr><tr><td><img src="/files/GMxVix3Kxsh9Ca9DIxN9" alt="" data-size="original"> <strong>Support</strong></td><td>Where to get support for Diffblue Cover.</td><td></td><td></td><td><a href="https://www.diffblue.com/support/">https://www.diffblue.com/support/</a></td></tr></tbody></table>


# SonarQube Warnings

How to address SonarQube warnings related to Diffblue Cover

There are various SonarQube warnings that may be issues for tests created by Diffblue Cover. This page lists common warnings and how to address them, if they can be addressed. Note that there are specific ways to address SonarQube warnings in the [Diffblue Cover Plugin](/features/cover-plugin/cover-plugin-admin/using-sonarqube-with-cover-plugin) and [Diffblue Cover CLI](/features/cover-cli/cover-cli-admin/using-sonarqube-with-cover-cli). This page is for an overview of the warnings you may see and how they can be addressed with any version of Diffblue Cover.

## Configurable Warnings

### Refactor this method to reduce the number of assertions from X to less than N

CLI only: Use the `--max-assertions-per-test=(N-1)` option to limit the number of assertions per test.

### Add at least one assertion to this test

There are two common causes for this warning.

1. An option has been given to Diffblue Cover to keep partial tests (docs for [plugin](/features/cover-plugin/writing-tests/partial-tests) or [CLI](/features/cover-cli/writing-tests/partial-tests)) or [skeleton tests](/features/cover-plugin/writing-tests/skeleton-tests). In this case, tests without assertions are expected and the tests should be completed manually.
2. This is due to SonarQube failing to recognize certain assertion methods. Most likely, you have to do the following:

   Add `org.springframework.test.web.servlet.ResultActions#andExpect` to the `customAssertionMethods` parameter for rule `S2699`. This explicitly tells SonarQube to treat `andExpect` as an assertion.

### Test method naming conventions

By default, Diffblue Cover’s test method naming complies with the pattern `[a-z][a-zA-Z0-9_]*` You can change the method naming template if you want to create test names without underscores, for example. See method name template for [plugin](/features/cover-plugin/cover-plugin-settings/test-naming#method-name-template) or [CLI](/features/cover-cli/writing-tests/test-naming#method-name-template).

## Unresolvable Warnings

Note that these warnings are where SonarQube and Diffblue Cover have different beliefs about what is best. These cannot be easily adjusted in Diffblue Cover, so the best approach is to suppress these or use other approaches as described for the [Diffblue Cover Plugin](/features/cover-plugin/cover-plugin-admin/using-sonarqube-with-cover-plugin) and [Diffblue Cover CLI](/features/cover-cli/cover-cli-admin/using-sonarqube-with-cover-cli).

### Change the assertion arguments to not compare dissimilar types

SonarQube may incorrectly flag this situation when testing that the `equals` method of a class returns `false` when called with differing types.

### Swap these two arguments so they are in correct order: expected value, actual value

This is not expected to happen. If you see this file a support request with a concrete example of test code generated by Cover.

### Replace these N tests with a parameterized test

Diffblue Cover currently does not support parameterized tests. This feature is on the roadmap. Stay tuned.

### Long variables

Diffblue Cover prefers long, descriptive variable names which may have up to about 40 characters.

### Local variable could be final

Local variables in tests generated by Diffblue Cover are never reassigned by construction. Diffblue Cover does not mark them using the `final` keyword.

### Unit test assertions should include message

Diffblue Cover does not generate such messages as they unnecessarily increase the verbosity and thus reduce the readability of the tests.

### Comment required for field

Diffblue Cover does not add JavaDoc comments to field declarations in test classes as they unnecessarily increase the verbosity and thus reduce the readability of the tests.


# Proof of Value

Diffblue’s Proof of Value (PoV) program aims to enable technical evaluation of Diffblue Cover in the context of the expected business value.

It is designed to be an in depth opportunity to learn about our autonomous AI-powered unit testing solution and to help customers validate their technical architecture and business processes in order to be able to effectively evaluate Diffblue Cover.

The solution, its practical application, and how it drives specific business value according to the specific use case you have in mind (examples below) are proven and documented throughout the PoV process.

<figure><img src="/files/2nfcFVBEMY0gCf66Lc9c" alt=""><figcaption></figcaption></figure>

### Advantages of working with the Diffblue PoV program

Our Proof of Value (PoV) exists to achieve the following.

* Help potential customers get the most out of Diffblue Cover in the shortest amount of time possible whilst understanding how it is like to work with Diffblue as a partner.
* Demonstrate the business value and tangible benefits of Diffblue Cover.
* Quantify efficiency gains, cost savings & other benefits that the solution brings.

The Diffblue PoV Program provides several advantages for potential customers looking to evaluate Diffblue Cover including the following.

* Direct access to Diffblue resources, tools and expertise to help customers accelerate their deployment and adoption.
* Ensures that potential customers are successful by providing guidance and best practices from Diffblue Solutions Architects.
* Builds a strong business case, by quantifying specific product benefits and aligning them with strategic objectives.

This guide is specifically intended as an overview of our PoV process and to help set expectations.

### Goal

With the Difflblue Cover Proof of Value program, we aim to identify your best deployment path to leveraging autonomous AI-powered unit test generation for your team/engineering organization and to demonstrate product value.

The goal is not to implement a complete product installation & process workflows. Instead, it’s intended to test and validate assumptions related to process, the core AI-driven technology and to demonstrate that the core feature capabilities are valuable.

Specifically, the goal is to prove that Diffblue Cover:

* writes high quality unit tests at scale,
* writes understandable human-like unit tests that compile,
* effectively prevents regressions, and
* significantly saves developer time/resources.


# Jumpstart

The Diffblue Jumpstart onboarding program ensures that your development teams quickly get value from Diffblue Cover. Our engineers teach your champions how to get the best from Diffblue Cover, help them integrate it into your software development lifecycle, and educate your developers on the best way to work with Diffblue tests.

After having set up the [prerequisites](/evaluation-and-onboarding/jumpstart/prerequisites-for-onboarding), Jumpstart proceeds in the following three phases.

1. [Up and running](/evaluation-and-onboarding/jumpstart/phase-1-up-and-running): help your champions set up Cover on your first projects and enable your champions to roll out to more projects on their own.
2. [Developer productivity](/evaluation-and-onboarding/jumpstart/phase-2-developer-productivity): teach your developers how to use Cover efficiently and understand the value that you get from Cover.
3. [Advanced topics](/evaluation-and-onboarding/jumpstart/phase-3-advanced-topics) (optional): tips and tricks to write more tests with Cover and improve the testability of your codebase as well as slash test execution times on your Pull Requests.


# Prerequisites for onboarding

We recommend to start onboarding with a handful of selected projects from different teams. A **project** is typically an application or a repository.

The onboarding of each selected project will be driven by a named champion. A **champion** is responsible for making the project ready for Diffblue Cover, creating the baseline and communicating with DevOps to set up Cover in CI. This is usually a team lead or a senior engineer on a team. They may already have been involved in an earlier proof-of-concept.

To facilitate communication among yourselves and with Diffblue, you should gather the following information.

1. Projects, teams and developers.
   1. To how many projects in total are you planning to roll out in the long-term?
   2. How many teams work on these projects in total?
   3. How many developers work on these projects in total?
2. Screensharing and log files.
   1. Please confirm which of the following the champions can share during working sessions:
      1. Console output of Diffblue Cover (contains identifier names).
      2. Cover log files (details can be provided on request).
      3. Cover Reports (coverage data).
      4. Snippets of build configurations (`pom.xml`, `build.gradle`, `build.xml`).
      5. Snippets of source code.
   2. Please confirm which of the following the champions can provide in support requests.
      1. Cover log files (details can be provided on request).
      2. Snippets of build configurations (`pom.xml`, `build.gradle`, `build.xml`).
      3. Snippets of source code.
3. Software and license distribution.
   1. Please describe the process from being notified about an update by a vendor to the software being available to a user. E.g. security scans, internal app stores.
   2. Please name a contact for software and license distribution.
4. Cover Reports installation.
   1. Please name a contact for installing the Cover Reports web-app so that it is accessible to all the teams.
5. Diffblue recommends to start onboarding with a handful of selected projects (3-5) from different teams. For each project, the following information should be provided.
   1. Name of the project.
   2. Name of the corresponding champion contact for each project.
   3. Name of the champion’s team and the team’s location in the organization hierarchy.
   4. SCM system (e.g. GitHub) of the project.
   5. CI system (e.g. Jenkins) of the project.
   6. Build System used by the project (e.g. Maven)
   7. Java version of the project.
   8. Operating system used by champion (e.g. Windows).
   9. IDE used by champion (e.g. IntelliJ).
   10. RAM (e.g. 16GB) and number of cores (e.g. 4) of the champion's workstation.

Once the information 1-5 has been received, Diffblue will send the software and licenses to the contact for software and license distribution.

6. You then need to [set up Cover Reports](/get-started/diffblue-learning/test-coverage/cover-reports-administrator) on a central server.
7. If the champions' workstations do not meet the[ required specfications for running Cover](/get-started/specs-and-reqs) then it is recommended to provision sufficiently powerful VMs with a development environment set up that allows to build the selected projects and run tests.
8. Champions [install Cover CLI](https://cover-docs.diffblue.com/evaluation-and-onboarding/jumpstart/pages/7V85GXh1MOFovvH55h1E#id-1.-install-diffblue-cover-cli), run [preflight](/features/cover-cli/project-configuration/preflight) on the selected projects and send the log files to <jumpstart@diffblue.com> for inspection to inform the subsequent Jumpstart agenda.


# Phase 1: Up and running

This phase will help your champions set up Cover on your first projects and enable your champions to roll out to more projects on their own.

1. [Create your Cover unit test baseline](/evaluation-and-onboarding/jumpstart/phase-1-up-and-running/module-1-create-your-cover-unit-test-baseline): validate the build configuration of your first projects with respect to unit testing and write a test baseline for your first projects.
2. [Cover CI Pipeline integration](/evaluation-and-onboarding/jumpstart/phase-1-up-and-running/module-2-cover-pipeline-ci-integration): integrate Cover into the CI system of your first projects.


# Module 1: Create your Cover unit test baseline

In this module, we will enable you to perform the first steps of onboarding a new project. These are:

1. make your first projects Cover-ready by validating the build configuration with respect to unit testing, and
2. write a test baseline for your first projects

### Prerequisites

To start this module, you need to satisfy the [prerequisites](/evaluation-and-onboarding/jumpstart/prerequisites-for-onboarding), which amount to having Cover installed at least to the level of [Reference Deployment 1](/get-started/reference-deployments#reference-deployment-1-no-ci-cd-system-available), i.e.

* [Cover Reports is installed](/get-started/diffblue-learning/test-coverage/cover-reports-administrator) on a central server.
* As a champion you have Cover CLI installed in a development environment that satisfies the requirements.
* You have run preflight and sent the log files to Diffblue.

### License activation

[Activate Cover CLI ](https://cover-docs.diffblue.com/evaluation-and-onboarding/jumpstart/phase-1-up-and-running/pages/7V85GXh1MOFovvH55h1E#id-2.-apply-a-license)using the license key that you received from the contact for software and license distribution in your organization:

```
dcover activate XXXX-XXXX-XXXX-XXXX
```

View your license details to check that the activation was successful:

```
dcover license
```

### Telemetry configuration

We will check that telemetry is correctly configured on your system.

Usage information is sent to

* External Diffblue telemetry server (Enterprise Edition users can opt out)
* Cover Reports (if configured)

[Telemetry is configured](/features/cover-plugin/cover-plugin-admin/telemetry) via one of

* \~/.diffblue/telemetry.properties, or
* Environment variables

Check that:

* External telemetry is configured according to your company policies.
* Cover Reports telemetry points to your central Cover Reports server.

### Make your project Cover-ready

We will work through the whole flow for creating baseline tests.

{% hint style="info" %}
You can find a worked example of the entire flow [here](#worked-example-baseline-creation-process-using-the-petclinic-demo-project).
{% endhint %}

{% hint style="info" %}
If your project has multiple modules we recommend that you start with a representative module. Once the selected module is working, repeat the steps on the other modules.

Note that you can run a specific module without changing your working directory by adding the following option to the `dcover` commands: [`--working-directory`](https://docs.diffblue.com/features/cover-cli/commands-and-arguments#working-directory) `your-selected-module`
{% endhint %}

We will start with the validation of your build configuration - and fixing it if necessary. We will also measure and upload your existing unit test coverage.

<table><thead><tr><th width="242">Step</th><th>Command</th></tr></thead><tbody><tr><td><strong>1. Build the project from its root</strong></td><td>E.g. <code>./mvnw install -DskipTests</code></td></tr><tr><td><strong>2. Check and fix the project environment</strong></td><td><p><code>dcover create</code> <a href="/pages/6NrsjMICKX4GuFDqhTrI"><code>--preflight</code></a></p><p><code>dcover</code> <a href="https://docs.diffblue.com/features/cover-cli/commands-and-arguments#refactor"><code>fix-build</code></a></p><p>If necessary, apply manual fixes to your build configuration</p></td></tr><tr><td><strong>3. Commit fixes</strong></td><td><p>As soon as preflight doesn't report any errors or warnings:</p><p><code>git checkout -b diffblue-baseline</code></p><p><code>git commit -a -m "Build configuration fixes for Diffblue"</code></p></td></tr><tr><td><strong>4. Measure and upload existing coverage</strong></td><td><p><code>dcover</code> <a href="https://docs.diffblue.com/features/cover-cli/commands-and-arguments#generate-reports-bundles"><code>coverage-reports</code></a></p><p><code>dcover</code> <a href="https://docs.diffblue.com/features/cover-cli/commands-and-arguments#upload-reports-bundles"><code>upload</code></a> <code>http://your-cover-reports:8080</code></p><p>View Cover Reports</p></td></tr></tbody></table>

### Create your unit test baseline

We are now ready to create the baseline tests.

<table><thead><tr><th width="242">Step</th><th>Command</th></tr></thead><tbody><tr><td><strong>5. Create the baseline tests and measure coverage</strong></td><td><code>dcover</code> <a href="https://docs.diffblue.com/features/cover-cli/commands-and-arguments#create-tests"><code>create</code></a> <a href="https://docs.diffblue.com/features/cover-cli/commands-and-arguments#coverage-reports"><code>--coverage-reports</code></a></td></tr><tr><td><strong>6. Commit the baseline tests</strong></td><td><p><code>git add `find . -name '*DiffblueTest.java'`</code></p><p><code>git commit -m "Diffblue baseline tests"</code></p></td></tr><tr><td><strong>7. Upload the baseline coverage</strong></td><td><code>dcover</code> <a href="https://docs.diffblue.com/features/cover-cli/commands-and-arguments#upload-reports-bundles"><code>upload</code></a> <code>http://your-cover-reports:8080</code></td></tr><tr><td><strong>8. Review results</strong></td><td><p>View Cover Reports</p><p>View created tests in IntelliJ</p></td></tr><tr><td><strong>9. Push the changes</strong></td><td><p><code>git push --set-upstream origin diffblue-baseline</code></p><p>Create a pull request and get it merged.</p></td></tr></tbody></table>

### What does Cover CLI do?

When running a Cover command, the execution proceeds in several phases.

<table><thead><tr><th width="170">Phase</th><th width="299">Description</th><th>Additional execution information</th></tr></thead><tbody><tr><td><strong>Detecting environment</strong></td><td>Every Cover command starts by performing environment health checks to detect whether the project environment is ready for the Cover command to run.</td><td>When using <a href="/pages/6NrsjMICKX4GuFDqhTrI"><code>--preflight</code></a>, Cover stops after this phase and outputs an <em>environment summary.</em></td></tr><tr><td><strong>Creating tests</strong></td><td>This phase performs the generation of tests class per class, method per method.</td><td><p>Only executed when using the <a href="https://docs.diffblue.com/features/cover-cli/commands-and-arguments#create-tests"><code>create</code></a> command.</p><p>Ends with a <em>summary</em> with number of tests created and issues encountered.</p></td></tr><tr><td><strong>Validating tests</strong></td><td>This phase validates the created tests, i.e. it removes non-compiling and failing tests.</td><td><p>Executed after test generation when using the <a href="https://docs.diffblue.com/features/cover-cli/commands-and-arguments#create-tests"><code>create</code></a> command.</p><p>Test validation can also be run separately using the <a href="https://docs.diffblue.com/features/cover-cli/commands-and-arguments#the-validate-command"><code>validate</code></a> command.</p></td></tr><tr><td><strong>Calculating coverage</strong></td><td>This phase calculates the coverage of manually written and Diffblue tests using JaCoCo.</td><td><p>Executed when passing the <a href="https://docs.diffblue.com/features/cover-cli/commands-and-arguments#coverage-reports"><code>--coverage-reports</code></a> option to the <a href="https://docs.diffblue.com/features/cover-cli/commands-and-arguments#create-tests"><code>create</code></a> command.</p><p>Coverage reports can also be generated separately using the <a href="https://docs.diffblue.com/features/cover-cli/commands-and-arguments#generate-reports-bundles"><code>coverage-reports</code></a> command.</p></td></tr><tr><td><strong>Upload to Cover Reports</strong></td><td>This phase uploads the coverage reports to Cover Reports.</td><td>Executed when running the <a href="https://docs.diffblue.com/features/cover-cli/commands-and-arguments#upload-reports-bundles"><code>upload</code></a> command.</td></tr></tbody></table>

### Understanding Cover's log output

Cover produces output with increasing degree of detail:

* Console output
* Console output with [`--verbose`](/features/cover-cli/commands-and-arguments#verbose)
* [User log file](/features/cover-cli/cover-cli-admin/log-files#user-logs)
* [Support log file](/features/cover-cli/cover-cli-admin/log-files#support-logs)

The log files are in the `.diffblue/log` directory below the directory from where Cover was run.

### Overview of CLI options

The following is a short list of the more pertinent options for creating baseline tests. Details of additional options can be found in the [Commands & Arguments](/features/cover-cli/commands-and-arguments).

* Select module to run on without changing directory, e.g. [`--working-directory`](https://docs.diffblue.com/features/cover-cli/commands-and-arguments#working-directory) `my-module/my-submodule`
* Exclude modules, e.g. [`--exclude-modules`](https://docs.diffblue.com/features/cover-cli/commands-and-arguments#exclude-modules) `my-module/to-exclude`
* Verbose console output: [`--verbose`](/features/cover-cli/commands-and-arguments#verbose)
* Prefer Maven over Gradle: [`--maven`](https://docs.diffblue.com/features/cover-cli/commands-and-arguments#maven)
* Test framework, e.g. [`--test-framework`](https://docs.diffblue.com/features/cover-cli/commands-and-arguments#test-framework) `junit-4`
* Active Spring profiles, e.g. [`--active-profiles`](https://docs.diffblue.com/features/cover-cli/commands-and-arguments#active-profiles) `test`
* Ignore style checks: [`--ignore-stylechecks`](https://docs.diffblue.com/features/cover-cli/commands-and-arguments#ignore-stylechecks)
* System properties, e.g. [`-D`](https://docs.diffblue.com/features/cover-cli/commands-and-arguments#define)`my.property=value`
* Environment variables, e.g. [`--environment`](https://docs.diffblue.com/features/cover-cli/commands-and-arguments#environment) `MYVAR=value`
* CLI help: `dcover help create`

Cover automatically figures out which entry point methods to write tests for. The set of methods can be restricted by [specifying inclusions and exclusions](https://docs.diffblue.com/features/cover-cli/commands-and-arguments/packages-classes-and-methods). E.g. to write tests only for the `OwnerController` class you can run `dcover create org.springframework.samples.petclinic.owner.OwnerController`

### What does Cover do during test generation?

To generate tests, Cover analyzes your project's bytecode. It runs your code, and thus operates in a sandbox. The sandbox runs in a separate service process which prohibits system calls (file system, network, etc) to protect your system from potentially detrimental functionality within your codebase (e.g. wiping your filesystem, spamming third party services).

Cover partitions your code into groups of methods under test that it is going to test. For each group of methods under test, Cover

* either produces tests
* or an output code that explains why it didn’t produce complete tests

### Understanding Cover's output codes

Output codes identify the [messages that Cover outputs](/features/output-codes), e.g. E052 - Missing dependency

The output code can be used to quickly look it up in docs: e.g. <https://diff.blue/E052>

There are different types of messages distinguished by the first letter in the output code:

* Informational messages:
  * Testability (T), reason for not writing tests (R)
* Warnings/errors:
  * Project environment (E) including coverage measurement and reports upload
  * Licensing (L)

### What does test validation do?

Validation ensures that generated tests compile and pass. This is essential for Cover's autonomous operation in your CI Pipeline.

You may see two output codes related to test validation:

* First, tests are compiled and run individually (W output code).
* Finally, tests are run via your build system (V output code).

### Coverage measurement

Cover uses JaCoCo for coverage measurement.

Cover distinguishes two types of tests:

* **Diffblue-controlled tests** (“Diffblue”)
  * Unchanged tests written by Cover
  * Automatically maintained by CI pipeline
* **User-controlled tests** (“manual”)
  * Manually written or modified Diffblue tests
  * Maintained by user
  * These include the *existing tests* that you have manually written before starting to use Cover.

### How to ask for support

Before reaching out, check for potential solutions in

* [the documentation](https://docs.diffblue.com)
* and [the forum](https://forum.diffblue.com)

More complex questions & issues [contact support depending on your support plan](https://www.diffblue.com/support/).

Requirements for Diffblue to handle your support case:

* Detailed description of what you did and the behavior you observe (compared with what you expect)
  * Diffblue Cover [*support log file*](/features/cover-cli/cover-cli-admin/log-files#support-logs)
  * Additionally, for [R code](/features/output-codes/r-reason-codes)-related questions, one of the following:
    * A *reproducer* (most valuable to be able to support): a piece of code that results in the the R code message that you see
    * A *code snippet* of the relevant code under test (useful, but with lower chances of success) and a [*partial test*](/features/cover-cli/writing-tests/partial-tests) (if there is one) with the R code

### Worked example: Baseline creation process using the Petclinic demo project

The prerequisites for running this example are:

* JDK 17 has been installed.
* [Cover Reports has been downloaded, unpacked locally](/get-started/diffblue-learning/test-coverage/cover-reports-administrator), and started by running `bin/cover-reports`
* The demo project has been cloned by running `git clone` [`https://github.com/diffblue/demo-spring-petclinic`](https://github.com/diffblue/demo-spring-petclinic)
* To use the `dcover fix-build` command in step 2, [these prerequisites](/get-started/specs-and-reqs#cover-refactor) must be met.

We will work through the whole flow for creating baseline tests.

<table><thead><tr><th width="242">Step</th><th>Command</th></tr></thead><tbody><tr><td><strong>1. Build the project from its root</strong></td><td><code>./mvnw install -DskipTests</code></td></tr><tr><td><strong>2. Check and fix the project environment</strong></td><td><p><code>dcover create --preflight</code></p><p><code>dcover fix-build</code></p></td></tr><tr><td><strong>3. Commit fixes</strong></td><td><p><code>git checkout -b diffblue-baseline</code></p><p><code>git commit -a -m "Build configuration fixes for Diffblue"</code></p></td></tr><tr><td><strong>4. Measure and upload existing coverage</strong></td><td><p><code>dcover coverage-reports</code></p><p><code>dcover upload http://localhost:8080</code></p><p><a href="http://localhost:8080">View Cover Reports</a></p></td></tr><tr><td><strong>5. Create the baseline tests and measure coverage</strong></td><td><code>dcover create --coverage-reports</code></td></tr><tr><td><strong>6. Commit the baseline tests</strong></td><td><p><code>git add `find . -name '*DiffblueTest.java'`</code></p><p><code>git commit -m "Diffblue baseline tests"</code></p></td></tr><tr><td><strong>7. Upload the baseline coverage</strong></td><td><code>dcover upload http://localhost:8080</code></td></tr><tr><td><strong>8. Review results</strong></td><td><p><a href="http://localhost:8080">View Cover Reports</a></p><p>View created tests in IntelliJ</p></td></tr><tr><td><strong>9. Push the changes</strong></td><td>We skip this step for the demo project.</td></tr></tbody></table>


# Module 2: Cover Pipeline CI integration

In this module we are going to help you integrate Cover Pipeline into the CI system of your first projects.

You will learn about Cover's [Reference Deployments](/get-started/reference-deployments) and decide which one is the best fit for you. We will then guide you towards the implementation of the chosen deployment.


# Phase 2: Developer productivity

In this phase we will teach your developers how to use Cover efficiently and understand the value that you get from Cover.

3. [Getting started using Cover](/evaluation-and-onboarding/jumpstart/phase-2-developer-productivity/module-3-getting-started-using-cover): enable your developers to use Cover efficiently in their daily workflows (CI Pipeline, CLI, IntelliJ plugin).
4. [Introduction to Cover Reports](/evaluation-and-onboarding/jumpstart/phase-2-developer-productivity/module-4-introduction-to-cover-reports): enable engineering managers to use Cover Reports to assess the value received from Diffblue Cover.


# Module 3: Getting started using Cover

We will enable your developers to use Cover efficiently in their daily workflows (CI Pipeline, CLI, IntelliJ plugin) on your first projects.

To start this module you must have completed [Phase 1](/evaluation-and-onboarding/jumpstart/phase-1-up-and-running).


# Module 4: Introduction to Cover Reports

We will show you how to use Cover Reports to assess the value received from Diffblue Cover.

To start this module you must have completed [Module 1](/evaluation-and-onboarding/jumpstart/phase-1-up-and-running/module-1-create-your-cover-unit-test-baseline).


# Phase 3: Advanced topics

In this phase we will enable you to make use of advanced functionality of Cover.

5. [Speed up your test execution](/evaluation-and-onboarding/jumpstart/phase-3-advanced-topics/module-5-speed-up-your-test-execution): slash test execution times with Cover Optimize in CI and locally.
6. [Getting more from Cover](/evaluation-and-onboarding/jumpstart/phase-3-advanced-topics/module-6-getting-more-from-cover): tips and tricks to write more tests with Cover and improve the testability of your codebase.


# Module 5: Speed up your test execution

We will show you how to slash test execution times with Cover Optimize in CI and locally.

To start this module you should have completed [Module 2](/evaluation-and-onboarding/jumpstart/phase-1-up-and-running/module-2-cover-pipeline-ci-integration).


# Module 6: Getting more from Cover

We will delve into advanced features of Cover that will allow you to write more tests and improve the testability of your codebase.

To start this module you must have completed [Module 1](/evaluation-and-onboarding/jumpstart/phase-1-up-and-running/module-1-create-your-cover-unit-test-baseline) or [Module 3](/evaluation-and-onboarding/jumpstart/phase-2-developer-productivity/module-3-getting-started-using-cover).

For each group of methods that Cover analyzes, it either creates tests or it outputs a code that explains why it was not able to write a test. These output codes are the starting point for making Cover write more tests. -> [Understanding output codes](/evaluation-and-onboarding/jumpstart/phase-1-up-and-running/module-1-create-your-cover-unit-test-baseline#understanding-covers-output-codes)

In many cases Cover can output a [partial test](/features/cover-cli/writing-tests/partial-tests) that shows how far Cover got with writing a test. The partial test allows you to better understand the output code in the context of your code. By debugging such a partial test, you can gather more information to identify what is required to make Cover write more tests. -> Methodology for [How to Increase Code Coverage with Diffblue Cover (Step-by-Step)](/features/tutorials/increase-code-coverage#effective-debugging)

### Toolbox for tweaking Cover

The three main levers to influence the behavior of Cover are:

* Mocking
  * Cover automatically decides what to mock. However, sometimes it may not know at what level it should mock or try to instantiate classes that rather should be mocked. You can instruct Cover to try to mock certain classes.
* Custom inputs
  * Cover automatically figures out which input values to use. However, some tests may require specific inputs, i.e. specific domain knowledge to initialize objects correctly. You can give hints to Cover to use certain values.
* Custom setup
  * Some projects rely on static state or use custom application configuration mechanisms that need to be called before running any test. Cover will not be able to figure that out. You make Cover execute specfied custom setup so that it can build its tests upon it.

There are multiple ways how to actuate these levers:

[Command line options](/features/cover-cli/commands-and-arguments#create-tests):

* for [mocking](/features/cover-cli/project-configuration/mocking): [--mock](/features/cover-cli/commands-and-arguments#mock), [--mock-static](/features/cover-cli/commands-and-arguments#mock-static), [--mock-construction](/features/cover-cli/commands-and-arguments#mock-construction)

[Cover Annotations](/features/cover-annotations):

* for [mocking](/features/cover-annotations/mocking-annotations)
* for [custom inputs](/features/cover-annotations/custom-input-annotations)

[Diffblue rules](https://docs.diffblue.com/features/cover-cli/writing-tests/custom-inputs):

* for [custom inputs](/features/cover-cli/writing-tests/custom-inputs)

Test factories:

* for custom inputs of more complex types; usually in combination with [annotations](/features/cover-annotations/interesting-value-annotations) or [Diffblue rules](/features/cover-cli/writing-tests/custom-inputs#factory-rule)

[Custom base class](https://docs.diffblue.com/features/cover-cli/writing-tests/custom-test-setup):

* for before/after methods and static setup

### Handling R013

Cover did not find inputs that wouldn’t cause a trivial exception, e.g. `NullPointerException`.

Causes:

* Very specific input values are needed.
* A hard-to-initialize object is needed.
* Static (global) state needs to be initialized.

Possible resolutions:

* Provide custom inputs.
* Rather than providing a fully initialized instance, mock the methods called from the code under test.
* Initialize static state in a @Before method using a custom base class.

Similar output codes: `R008`, `R081`, `R082`, `R083`.

### Handling R026

Cover automatically figures out what Spring test context to load. Sometimes this fails because Spring configurations are missing for loading a test context.

Resolution approach:

1. Use [Commands & Arguments](/features/cover-cli/commands-and-arguments#keep-partial-tests) command line option `--keep-partial-test`
2. Run the created partial test and examine the obtained Spring exception
3. Manually fix the code until the test passes
4. Run Cover again

(3) may involve

* Adding an application-test.properties file.
* Adding a Spring @Configuration class providing @Bean definitions for testing purposes.
* Adding an additional class to the test context: use the `--spring-configuration` option, see [Commands & Arguments](/features/cover-cli/commands-and-arguments#spring-configuration).

If you decide that a Spring context should not be loaded, use the `--no-spring-tests` option, see [Commands & Arguments](/features/cover-cli/commands-and-arguments#no-spring-tests).

Similar output codes: `R027`

### Handling R011

Cover runs snippets of your code.

* In order to protect your system, it runs them in a sandbox.
* The sandbox forbids potentially dangerous operations, e.g. network access.

Cause:

* Your code calls a method that performs a forbidden operation.

Possible resolutions:

* Mock the operation so that it doesn’t get called.
* Verify that the operation is harmless and run with [`--disable-sandbox`](/features/cover-cli/writing-tests/diffblue-sandbox). ⚠

Similar output codes: [R012](https://docs.diffblue.com/features/output-codes/working-with-output-codes/working-with-code-r012)


# Cover Plugin

How to use Diffblue Cover Plugin for IntelliJ to write Java unit tests

Diffblue Cover Plugin automatically writes Java unit tests for your classes and methods directly within the IntelliJ IDE. This set of topics provides all the details you need - for getting started information (installation, licensing, and test examples), see [Get started - Cover Plugin](/get-started/get-started/get-started-cover-plugin).

<table data-card-size="large" data-view="cards"><thead><tr><th data-type="files"></th><th></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td></td><td><p><mark style="color:blue;"><strong>Write Tests</strong></mark></p><p>Automatically write unit tests for your methods and classes directly in your IDE.</p></td><td></td><td><a href="/pages/ZftYR0DSkDUlwJeZB4qc">/pages/ZftYR0DSkDUlwJeZB4qc</a></td></tr><tr><td></td><td><p><mark style="color:blue;"><strong>Configure Your Projects</strong></mark></p><p>Set up your projects to get the best tests from Diffblue Cover.</p></td><td></td><td><a href="/pages/o9wMDReRjHqbTuq3qeac">/pages/o9wMDReRjHqbTuq3qeac</a></td></tr><tr><td></td><td><p><mark style="color:blue;"><strong>Update Your Settings</strong></mark></p><p>Make Cover Plugin work your way - update the Diffblue Cover settings in IntelliJ.</p></td><td></td><td><a href="/pages/EdoIpG8mg32SMjN2Unrn">/pages/EdoIpG8mg32SMjN2Unrn</a></td></tr><tr><td></td><td><p><mark style="color:blue;"><strong>Admin</strong></mark></p><p>Get your admin done, including telemetry config, log files, memory management, etc.</p></td><td></td><td><a href="/pages/a4AotR9GZjPifJES5RKY">/pages/a4AotR9GZjPifJES5RKY</a></td></tr></tbody></table>

## eLearning

Just in case you missed our getting started video.

{% embed url="<https://youtu.be/wQ-W8Q5FYBU?feature=shared>" %}


# Writing tests

How to write tests using Cover Plugin for IntelliJ

To write tests using Cover Plugin for IntelliJ:

<table><thead><tr><th width="226">IntelliJ</th><th>Action</th></tr></thead><tbody><tr><td>Editor Panel</td><td>Click the <img src="/files/4lkNDIk55EL8087NS6kl" alt="" data-size="line"> <a href="/pages/H9LZtPMiJPWmU92BMWFN">Write Tests gutter icon</a>.</td></tr><tr><td>Editor Panel</td><td>Right-click a method or class and select <code>Write Tests</code>.</td></tr><tr><td>Editor Panel</td><td>Select <code>Diffblue</code> > <code>Write Tests</code> from the <a href="/pages/Dti3AM5yb7IYXls9Atm6#diffblue-menu-bar">IntelliJ menu</a>.</td></tr><tr><td><a href="/pages/Dti3AM5yb7IYXls9Atm6#project-tool-window">Project Tool Window</a></td><td>Right-click a folder or file and select <code>Write Tests</code>.</td></tr><tr><td><a href="/pages/Dti3AM5yb7IYXls9Atm6#structure-tool-window">Structure Tool Window</a></td><td>Right-click a method or class and select <code>Write Tests</code>.</td></tr><tr><td><a href="/pages/XL3e86vr9n1K2LCzMxNb">Run Configurations</a></td><td>Select <code>Run > Edit Configurations</code> from the IntelliJ menu.</td></tr></tbody></table>

{% hint style="info" %}
Once started, if you need to cancel the test writing process at any point, click the red **Stop** button in the [Cover Plugin tool window](/features/cover-plugin/writing-tests/diffblue-cover-tool-window).
{% endhint %}

In general, if the **Write Tests** option is available then Cover Plugin can write tests for your methods or classes. However:

* If it is not possible for Cover to write a complete test, instead a partial test may be created - see [Creating partial tests](/features/cover-plugin/writing-tests/partial-tests).
* If you don't want to write a complete test, Cover Plugin can help set up your tests by creating a skeleton test instead - see [Creating skeleton tests](/features/cover-plugin/writing-tests/skeleton-tests).


# Gutter icons

Cover Plugin for IntelliJ gutter icons

Cover Plugin provides several icons in the "gutter" area next to methods and classes in the IntelliJ editor panel - click the icon displayed to write, update, or delete tests.

## Action icons

<table><thead><tr><th width="111">Icon</th><th>Description</th></tr></thead><tbody><tr><td><img src="/files/PUlGQkG1lpbot5iLG8rq" alt="" data-size="original"></td><td>Displayed next to testable methods or classes in project files. Click the icon to write tests for the method or class.</td></tr><tr><td><img src="/files/UAT12CrVjE8GZWsMqAbm" alt="" data-size="original"></td><td>Displayed next to test classes and methods in project test files. Click the icon to update or delete tests for the method or class.</td></tr><tr><td><img src="/files/xYVvAhQZobYMjBXzdeUk" alt="" data-size="original"></td><td>Displayed next to your test methods in project test files. Click the icon to delete a test method.</td></tr></tbody></table>

## Status icons

<table><thead><tr><th width="116">Icon</th><th>Description</th></tr></thead><tbody><tr><td><img src="/files/vuGDoDZTSP54PCfxkxeo" alt="" data-size="original"></td><td>Indicates that Cover Plugin is unable to create tests for this method, unless the method is refactored to make it more testable. To allow Cover Plugin to write tests for such a method, the class should be extracted as an accessible named class.</td></tr><tr><td><img src="/files/bQh7cT6v1GBYzvC6j4Bb" alt="" data-size="original"></td><td>Indicates that Cover Plugin is unable to create tests that directly call this item, and that this is "by design". For example, Cover Plugin can't write tests for private methods.</td></tr></tbody></table>

## Disable the icons

To disable the icons in IntelliJ:

1. Go to `File -> Settings`.
2. Select `Editor -> General -> Gutter Icons`.
3. In the `Diffblue Cover` section, uncheck the boxes corresponding to the icons you want to disable.


# Menu options

Where to find the Write Tests menu option and how it can be used

The `Write Tests` menu option can be used throughout IntelliJ:

* Right click in the [Project Tool Window](#project-tool-window).
* Right click in the [Structure Tool Window](#structure-tool-window).
* Right click in the [Text Editor](#text-editor).
* Use the [Diffblue Menu Bar](#diffblue-menu-bar).

The `Write Tests` menu option will create tests for your methods and classes but each menu option works slightly differently to produce tests for different parts of your code.

## Project Tool Window

When navigating through your project, you'll likely use the project tool window in IntelliJ. Right-click on any of the elements and select `Write Tests`. Diffblue Cover will attempt to write tests for everything it can find within that package (license limitations may apply).

<div align="left"><figure><img src="/files/zdqWtNXePVvYm6Fk1Rkr" alt="" width="563"><figcaption></figcaption></figure></div>

You can also select multiple classes with `Shift` or `CTRL` (`CMD` on MacOS). Cover will attempt to write tests for every class within your selection.

<div align="left"><figure><img src="/files/dniIo7hb6IpcJ6QPWUXV" alt="" width="563"><figcaption></figcaption></figure></div>

## Structure Tool Window

Similar to the Project Tool Window, IntelliJ provides a Structure menu to help you navigate around your codebase. In particular, the structure menu will show classes, methods and other elements in the currently open file. As with the Project Tool Window, right-click on any method in the Structure Tool Window and select `Write Tests`, and you can also select multiple methods with `Shift` or `CTRL` (`CMD` on MacOS).

<div align="left"><figure><img src="/files/Nze2KhMFFguKMdZWWQkV" alt="" width="563"><figcaption></figcaption></figure></div>

## Text Editor

In the IntelliJ editor panel, you can right-click a method or class to display the `Write Tests` menu option - an alternative to the gutter icon, but also allows you to right-click anywhere within a class or method.

<div align="left"><figure><img src="/files/LCXvwFBikJLvi14TTSsW" alt="" width="563"><figcaption></figcaption></figure></div>

The menu option is also available when making one or more editor selections.

<div align="left"><figure><img src="/files/4qWrgIogijRhHFR7VWjk" alt="" width="563"><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="/files/VZXzHwIeeid0K6PbnWfE" alt="" width="563"><figcaption></figcaption></figure></div>

## Diffblue Menu Bar

The `Write Tests` menu option is also available from the Diffblue menu bar. This will perform the exact same function as the menu option in the text editor.

<div align="left"><figure><img src="/files/kxcjBOiqaxHnka9QgIY5" alt="" width="443"><figcaption></figcaption></figure></div>


# Run configurations

How to configure the run configurations in IntelliJ for writing tests.

Run configurations allow you to configure the environment variables and system properties that are used when Cover Plugin creates tests. It also allows you to manually specify the method, class, package, or prefix for writing tests.

## Dialog

The IntelliJ run configuration dialog for Diffblue Cover contains the following elements:

* **Name** - Provide a useful name for the run configuration.
* **Store as project file** - If selected, the run configuration will be stored as a project file.
* **Test creation target** - Select All in package, Class, Method, or Prefixes from the drop down to set the scope of items you're writing tests for. Enter the target details as appropriate.
* **Write skeleton tests** - If selected, Cover Plugin will write skeleton tests instead of creating complete tests. See [Creating skeleton tests](/features/cover-plugin/writing-tests/skeleton-tests) for more information.
* **Environment Variables** - Provide a list of key/value pairs to set environment variables.

{% hint style="info" %}
To display the dialog box, go to `Run > Edit Configurations`. If needed, click `Add New Configuration` (the **+** button) and select `Diffblue Cover`.
{% endhint %}

<div align="left" data-full-width="false"><figure><img src="/files/sxjwFSXV5DwvTPsZjsVj" alt="" width="563"><figcaption></figcaption></figure></div>

To access the system properties setting, click the `Modify options` button, and select `Add VM Options`. The `VM option` text box is added to the Run Configuration options - use this to add JVM system properties in the standard format, for example `-Dkey1=value1`.

<div align="left"><figure><img src="/files/nrdnUL4hMQ77P85spDCI" alt="" width="563"><figcaption></figcaption></figure></div>

## Creating a run configuration

### Automatic creation

When you write tests with Cover Plugin a run configuration is created for your selection. For example, suppose we have the sample below:

```java
package com.example;

public class StringUtils {

  public static boolean isPalindrome(final String s) {
    for (int i = 0; i < s.length() / 2; i++) {
      char first = s.charAt(i);
      char second = s.charAt(s.length() - 1 - i);
      if (first != second) {
        return false;
      }
    }
    return true;
  }
}
```

If you write tests for the method, the run configuration that is created will look like the following (to display the dialog box, go to `Run > Edit Configurations` and select the appropriate configuration from the list):

<div align="left"><figure><img src="/files/8nUa9nf3TXw63WwrZjdn" alt="" width="563"><figcaption></figcaption></figure></div>

You will notice there's a split between the class name and the method name, and that the method includes the signature of the method you've selected – this is the `(Ljava/lang/String;)Z` string after the colon.

### Manual creation

To create a run configuration "manually", go to `Run > Edit Configurations`, click `Add New Configuration` (the **+** button) and select `Diffblue Cover`.

First select the scope, then use the `Browse` action on the class/package (and method, if appropriate) to make your selection. If you've selected the method scope, the signature will be populated for you.

<div align="left"><figure><img src="/files/W3svN71H9b1F5gZ2wxxV" alt="" width="563"><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="/files/tqvovG54zocJSOQcBDVO" alt="" width="563"><figcaption></figcaption></figure></div>

## Template

If you have a particularly large list of system properties or environment variables that you would like to use every time you use Cover Plugin to write tests, you can specify a *template*. (`File > New Projects Setup > Run Configuration Templates > Diffblue Cover`). The values you specify will be used for any future run configurations.

## Prefixes

If required, you can specify what packages, classes, or methods you want to restrict these operations to, by specifying one or more prefixes in the run configuration.

**Example:** `io.corebanking.Account`

***

### Package example

Specify a package entry point using the standard Java naming convention, plus an optional trailing dot.

**Syntax:** `<path>[.]`

***

**Trailing dot:** `<path>.`

**Example:** `com.a.`

**Description:** Write tests for all accessible methods within package `<path>` (in our example, `com.a`) and any sub-packages. For example, tests could be written for sub-packages `com.a.B` and `com.a.b.C`

***

**No trailing dot:** `<path>`

**Example:** `com.a`

**Description:** Write tests for all accessible methods within any package that begins with `<path>` (in our example, `com.a`) and any sub-packages. For example, tests could be written for `com.a`, `com.apple`, `com.apricot`, `com.apricot.pip`, etc.

***

### Class example

Specify a class entry point using the standard Java naming convention, plus an optional trailing dot.

**Syntax:** `<path>[.]`

***

**Trailing dot:** `<path>.`

**Example:** `io.diffblue.corebanking.account.Account.`

**Description:** Write tests for all accessible methods within class `<path>` only - in our example, `io.diffblue.corebanking.account.Account`.

***

**No trailing dot:** `<path>`

**Example:** `io.diffblue.corebanking.account.Account`

**Description:** Write tests for all accessible methods within any class that begins with `<path>` - in our example, this could include `...Account` and `...AccountException`.

***

### Method example

Specify a method entry point using the standard Java naming convention, plus an optional method descriptor.

**Syntax:** `<path>:[<methodDescriptor>]`

**Example:** `io.diffblue.corebanking.account.Account.addToBalance:`

**Description:** Write tests for the specified method. If the optional method descriptor is omitted, all parameter and return types will be included.

A method descriptor is a list of type descriptors that describe the parameter types and the return type of a method, in a single string. For more information on method descriptors, see section 2.1.4 of the [ASM 4.0 A Java bytecode engineering library](https://asm.ow2.io/asm4-guide.pdf).


# Cover Plugin tool window

Diffblue Cover tool window in Cover Plugin

When writing tests, the Cover Plugin tool window is displayed. The Overview panel provides summary progress and status information for each stage when writing tests - click an item to review detailed status and results in the Details panel, including preflight and environment check results, a Diff Viewer for reviewing tests written, test links, output codes, and general information.

<figure><img src="/files/VQs2QaWZMPIxYdlrljyp" alt=""><figcaption></figcaption></figure>

## Preparing

During this stage, Cover Plugin runs initial checks to ensure it can write tests. If there are any issues, the Overview panel will tell you which check failed, along with an explaination to help you resolve it. Example issues may include problems with licensing or compiling the project.

<figure><img src="/files/tgJfZJONnwkurjjW1oms" alt=""><figcaption></figcaption></figure>

## Checking environment

Next, Cover Plugin will check your project's environment, to make sure it is set up correctly. This checks your project and its dependencies against Diffblue [specifications and requirements](/get-started/specs-and-reqs). If Cover Plugin detects something outside of these requirements you may see warnings or errors in the Details panel - these can be expanded to display more information to help you resolve the issue and some may have automatic fixes (see [#fix-issues](#fix-issues "mention") below).

<figure><img src="/files/Hi0yDtDCj2C9HFw6i5bz" alt=""><figcaption></figcaption></figure>

### Fix issues

Certain errors and warnings reported during the **Checking environment** stage may have automated fixes available - click the **Fix Issue** button in the Details panel and Cover will attempt to automatically apply the fix to your project.

<figure><img src="/files/vEyHfzER811jA06s7sR1" alt=""><figcaption></figcaption></figure>

## Writing tests

Finally, Cover Plugin will write your tests. The Overview panel displays the progress for each method (grouped by class) - select an item to review created tests, as well as to view details such as test links and general information for your tests once they have been reviewed.

<figure><img src="/files/XnEayf1WNdyUyA5bImuH" alt=""><figcaption></figcaption></figure>

## Cancel tests

If you need to cancel test creation at any point, click the red **Stop** button.

<figure><img src="/files/5TprLv8nMpmd2YVy3mah" alt="" width="375"><figcaption></figcaption></figure>

When you click **Stop**, any remaining methods will be marked as cancelled and tests will not be created for them. Any tests that have already been written will be retained for review and can be merged into your codebase once accepted.

Note that cancelling test creation may not happen immediately. Cover will attempt to stop gracefully, so you may have to wait for its current progress to complete before the process is halted.

<figure><img src="/files/Nio3D3ydRmvkKMMbESLI" alt=""><figcaption></figcaption></figure>

## Restart test generation

Once test generation has finished, you can click on the restart button to rerun the test generation process.

<figure><img src="/files/ayuVPsmkwUr4QCXAk1s9" alt="" width="375"><figcaption></figcaption></figure>

When you click **Restart**, the tool window will be cleared and Cover will attempt to write tests on the exact same configuration of methods or classes.

## Open logs

Please see [**accessing logs** ](/features/cover-plugin/cover-plugin-admin/log-files#accessing-logs)for more information.

## Open Support request

If you need to raise a support request, click the **Open support request** button (not available for all users, please see [Cover Editions](/updates-and-upgrades/cover-editions) for more details).

<div align="left"><figure><img src="/files/G2WK17j6y8uLqMbF9G9O" alt=""><figcaption></figcaption></figure></div>


# Test Review

Test Review allows you to edit, analyse and manage each of the tests Diffblue Cover creates for you, as soon as those tests are available.

When enabled, you are given the opportunity to review and change the tests before they get added to your codebase.

## Beginning a review

To perform a review, simply write tests as normal. The number of tests available for review is shown in the tool panel. Once the first test is created the `Review Now` button will become active; clicking this will take you to the first test waiting to be reviewed.

<figure><img src="/files/XnEayf1WNdyUyA5bImuH" alt="" width="563"><figcaption></figcaption></figure>

## Reviewing a test

To help you review your tests, we display them inside a [Diff Viewer](https://www.jetbrains.com/help/idea/comparing-file-versions.html). When comparing side-by-side, on the left you'll see your original test file (the file your tests will be inserted into). On the right, you'll see Diffblue Cover's test suggestion. This includes the test that has been created, as well as any other modifications to the test class required for the test to run.

You can use any of the features of the Diff Viewer to help you review your test, you can even edit the test inside the Diff Viewer if you wish.

<figure><img src="/files/rxYJv7P6TX7El9E33nxm" alt="" width="563"><figcaption></figcaption></figure>

{% hint style="info" %}
You must accept any test that you wish to edit in the Diff Viewer. All changes made will be lost when you navigate away from the test.
{% endhint %}

### Accepting a test

Once you're happy with the test suggestion, you must accept it for the test to be added to your test file. If you have edited the test, these changes will be included when you accept.

<figure><img src="/files/2JeIAS8ozyHgTieGLTAe" alt="" width="563"><figcaption></figcaption></figure>

{% hint style="warning" %}
Any tests that are not accepted will be lost and can only be recreated by running Diffblue Cover again on the method under test. Please make sure you accept any test you want to keep.
{% endhint %}

### Accepting all tests

You might wish to inspect each test, and accept them all in one action. In which case, when you are happy with your tests, you can use the dropdown menu of the accept button and click "Accept all".

### Rejecting a test

If you do not wish to keep a test suggestion, for whatever reason, you can reject it. All tests can be rejected in one click using the "Reject all" option within the dropdown menu of the reject button.

{% hint style="warning" %}
Once a test is rejected, it is lost. Rejected tests can only be recreated by running Diffblue Cover again on the method under test.
{% endhint %}

## Navigating through tests

Once you have accepted or rejected a test, you will be automatically taken to the next test requiring your review.

However, If you wish to inspect multiple tests before taking an action, or you wish to review a specific test, you can navigate through the tests to find what you want. The tree on the left displays all methods under test. If a method has any test requiring review, it will display a ![](/files/cFaTOvBZYhbdzifEsJIC) icon. Once all tests for the method have been reviewed, this icon will be replaced according to the status of the tests.

<figure><img src="/files/kDoj9HSbeq4l94Z7W7nw" alt="" width="563"><figcaption></figcaption></figure>

There may be situations where Diffblue Cover creates multiple tests for a single method. In this case, a list of test methods will appear on the left. You can click through the items in this list to review the tests you're most interested in. This list can be resized or collapsed at any point while it is open.

<figure><img src="/files/NwGhyyVtcel6rkt6FF5o" alt="" width="563"><figcaption></figcaption></figure>

Alternatively, you can navigate through these tests with the left/right arrow icons below the Diff Viewer.

<figure><img src="/files/eOQBLJ2EQNAmCN3mZA6Z" alt="" width="563"><figcaption></figcaption></figure>

## Enabling/Disabling Test Review

From Diffblue Cover IntelliJ Plugin 2025.03.01, Test Review is enabled by default - but it can be turned on or off at any time. When Test Review is disabled, tests will automatically be accepted and merged into your codebase.

To enable or disable Test Review, follow these steps:

1. Open the Diffblue Settings menu via `Diffblue` -> `Change Settings`
2. Find the section titled "Test Review".
3. Check or uncheck the `Test Review` checkbox.
4. Apply the settings.

<figure><img src="/files/qHiO5eKiEamSUTeCAolt" alt="" width="563"><figcaption></figcaption></figure>


# Test examples

In this topic we show both the input source code, and the tests written by Diffblue Cover, for code of varied complexity, accompanied by a detailed narrative to help you further understand tests created by Diffblue Cover.

***

## Basic assertions <a href="#id-1-basic-assertions" id="id-1-basic-assertions"></a>

This is a simple example of Spring Service source code with a trivial getter. Cover can write a Spring Boot test for the getter in a service provider by inlining `Arrange`, `Act`, and `Assert`.

**Source**

```java
import org.springframework.stereotype.Service;

@Service
public class SimpleService
{
  public String getValue() {
    return "a really simple service";
  }
}
```

#### Test written by Diffblue Cover <a href="#id-12-test-generated-by-diffblue-cover" id="id-12-test-generated-by-diffblue-cover"></a>

```java
@SpringBootTest
@RunWith(org.springframework.test.context.junit4.SpringRunner.class)
public class SimpleServiceDiffblueTest {
  @Autowired
  private SimpleService simpleService;
  @Test
  public void diffbluetestGetValue() {
    // Arrange, Act and Assert
    assertEquals("a really simple service", this.simpleService.getValue());
  }
}
```

***

## Mocking <a href="#id-2-mocking" id="id-2-mocking"></a>

This is a class that contains two methods to upload and download a file to/from an Amazon S3 bucket. As the Amazon S3 bucket is a cloud storage mechanism, the test for this class/methods requires dependency injection. Cover can mock these types of dependencies and tests `downloadFileFromBucket` method by asserting the expected `S3Object` and the downloaded `S3Object` using the method.

#### Source <a href="#id-21-source" id="id-21-source"></a>

```java
@Service
public class AmazonService {

  @Autowired
  private AmazonS3 s3client;

  public PutObjectResult uploadFileToBucket(String bucketName, String key, File file) {
    return s3client.putObject(bucketName, key, file);
  }

  public S3Object downloadFileFromBucket(String bucketName, String key) {
    return s3client.getObject(bucketName, key);
  }
}
```

#### Tests written by Diffblue Cover <a href="#id-22-tests-generated-by-diffblue-cover" id="id-22-tests-generated-by-diffblue-cover"></a>

```java
@SpringBootTest
public class AmazonServiceDiffblueTest {
  @MockBean
  private AmazonS3Client amazonS3Client;
  @Autowired
  private AmazonService amazonService;
  @Test
  public void diffbluetestUploadFileToBucket() {
    // Arrange
    PutObjectResult putObjectResult = new PutObjectResult();
    putObjectResult.setContentMd5("file-hash");
    when(this.amazonS3Client.putObject(or(isA(String.class), isNull()), or(isA(String.class), isNull()),
        or(isA(File.class), isNull()))).thenReturn(putObjectResult);

    // Act and Assert
    assertSame(putObjectResult, this.amazonService.uploadFileToBucket("foo", "foo",
        Paths.get(System.getProperty("java.io.tmpdir"), "test.txt").toFile()));
  }
  @Test
  public void diffbluetestDownloadFileFromBucket() throws UnsupportedEncodingException {
    // Arrange
    StringInputStream objectContent = new StringInputStream("file-name");
    S3Object s3Object = new S3Object();
    s3Object.setObjectContent(objectContent);
    when(this.amazonS3Client.getObject(or(isA(String.class), isNull()), or(isA(String.class), isNull())))
        .thenReturn(s3Object);

    // Act and Assert
    assertSame(s3Object, this.amazonService.downloadFileFromBucket("foo", "foo"));
  }
}
```

***

## OS agnostic assertions <a href="#id-3-os-agnostic-assertions" id="id-3-os-agnostic-assertions"></a>

This example returns time in a different format. Cover writes a test to assert date and time that is not dependent on operating system or local time zones.

#### Source <a href="#id-31-source" id="id-31-source"></a>

```java
public class TimeInAliceWonderland {

  private static final String DODO_DATETIME_FORMAT = "ss:mm:HH dd-MMM-yyyy";

  public static String reformatDodoDateTime(Date humanDate) {
    Map<String, DateFormat> dateFormatMap = new HashMap<>();
    dateFormatMap.put(DODO_DATETIME_FORMAT, new SimpleDateFormat(DODO_DATETIME_FORMAT));
    return dateFormatMap.get(DODO_DATETIME_FORMAT).format(humanDate);
  }
}
```

#### Test written by Diffblue Cover <a href="#id-32-test-generated-by-diffblue-cover" id="id-32-test-generated-by-diffblue-cover"></a>

```java
@Test
  public void diffbluetestReformatDodoDateTime() {
    LocalDateTime atStartOfDayResult = LocalDate.of(1970, 1, 1).atStartOfDay();
    assertEquals("00:00:00 01-Jan-1970", TimeInAliceWonderland
        .reformatDodoDateTime(
            Date.from(atStartOfDayResult.atZone(ZoneId.systemDefault()).toInstant())));
  }
```

***

## Example containing logic <a href="#id-4-example-containing-logic" id="id-4-example-containing-logic"></a>

In this example, Cover writes two tests to cover each pathway through the conditional - a test which adds 10 to the balance and asserts the new balance should be 20 and a second test where the account is closed.

#### Source <a href="#id-41-source" id="id-41-source"></a>

```java
public class Account {
  private final long accountNumber;
  private final Client client;
  private long currentBalance;
  private String accountName;
  private AccountState accountState;

  public Account(final long accountNumber, final Client client, final long amount) {
    this.accountNumber = accountNumber;
    this.client = client;
    currentBalance = amount;
    accountName = "Current";
    accountState = AccountState.OPEN;
  }

  public long getCurrentBalance() {
    return currentBalance;
  }

  public void addToBalance(final long amount) throws AccountException {
    if (getAccountState() != AccountState.OPEN) {
      throw new AccountException("Cannot add to balance, account is closed.");
    }
    currentBalance += amount;
  }
```

#### Test written by Diffblue Cover <a href="#id-42-test-generated-by-diffblue-cover" id="id-42-test-generated-by-diffblue-cover"></a>

```java
 @Test
  public void diffbluetestAddToBalance() throws AccountException {
    // Arrange
    Account account = new Account(1234567890L, new Client("Carlos Welch"), 10L);

    // Act
    account.addToBalance(10L);

    // Assert
    assertEquals(20L, account.getCurrentBalance());
  }
```

***

## Example of complex logic <a href="#id-5-example-of-complex-logic" id="id-5-example-of-complex-logic"></a>

This example code has three branches - Cover covers 100% of branches and creates three tests for three cases using existing enum values.

#### Source <a href="#id-51-source" id="id-51-source"></a>

```java
public class VirtualSnackCupboard {

  public static Snack whatCanISnackNow(int oClock) {
    if (oClock == 10) {
      return Snack.CHOCOLATE;
    } else if (oClock == 15) {
      return Snack.CAKES;
    } else {
      return Snack.VEGGIE;
    }
  }
  enum Snack {VEGGIE, CHOCOLATE, CAKES}
}
```

#### Tests written by Diffblue Cover <a href="#id-52-tests-generated-by-diffblue-cover" id="id-52-tests-generated-by-diffblue-cover"></a>

```java
  public void diffbluetestPickSnack() {
    assertEquals(VirtualSnackCupboard.Snack.CHOCOLATE, VirtualSnackCupboard.whatCanISnackNow(10));
    assertEquals(VirtualSnackCupboard.Snack.CAKES, VirtualSnackCupboard.whatCanISnackNow(15));
    assertEquals(VirtualSnackCupboard.Snack.VEGGIE, VirtualSnackCupboard.whatCanISnackNow(0));
  }
```

***

## Testing trivial methods

Diffblue Cover CLI deliberately does not test trivial methods such as getters, setters, constructors and factory methods to avoid creating large quantities of noisy tests that do not contribute to overall coverage. There isn't a benefit to be gained from testing these trivial methods directly as, for example, getters and setters simply access attributes so there is no actual logic to be tested. Similarly, constructors and factory methods also contain little or no logic. If Diffblue Cover CLI did test such methods directly, a minor coverage increase might be gained, but this "improvement" would be meaningless in terms of improving code quality.

Ultimately these trivial methods will be covered when Cover generates tests for other methods that call these trivial methods. Diffblue recommends improving the percentage of coverage using the many options within the product, as shown in the [Commands & Arguments](/features/cover-cli/commands-and-arguments) topic.


# Creating partial tests

By default, creation of partial tests is enabled in the Diffblue Cover Plugin for IntelliJ. This page covers partial tests and their uses, and how to turn off this option.

## About partial tests

Normally, selecting <img src="/files/4lkNDIk55EL8087NS6kl" alt="" data-size="line"> or `Write Tests` will create *complete* tests for a method. A complete test consists of Arrange, Act, and Assert sections and passes when executed. However, sometimes Diffblue Cover is not (yet) able to write complete tests and will give the reason for not producing complete tests in the Diffblue Cover tool window. In these cases, Diffblue Cover will create *partial* tests - these tests may be incomplete in various aspects:

* The test does not have assertions.
* The test does not always pass when executed.
* The Arrange or Act sections produce an error when executed.
* The test may execute code that is potentially harmful to your system, leaks resources or times out.

Creating such tests is useful to developers for two reasons:

* Firstly, it will save developers time. Instead of writing tests from scratch, they'll be able to use the partial tests as a starting point.
* Secondly, it may help developers understand why Diffblue Cover was not able to *complete* the test automatically, especially in cases where the reason for not producing a test is lack of testability.

For example, for the method `increment` in the following class:

```java
public class MyClass {
    private int x;
    public void increment() {
	  ++x;
    }
}
```

Diffblue Cover will create a *partial* test:

```java
  @Test
  public void testIncrement() {
    // TODO: This test is incomplete.
    //   Reason: R002 Missing observers.
    //   Diffblue Cover was unable to create an assertion.
    //   Add getters for the following fields or make them package-private:
    //     MyClass.x

    // Arrange
    MyClass m = new MyClass();

    // Act
   m.increment();
  }
```

The problem is clearly that Diffblue Cover has no opportunity to assert on the side effect of the `increment` method on field `x`, which is marked `private`. The developer could add a getter to `MyClass`:

```java
public class MyClass {
    private int x;
    public void increment() {
	  ++x;
    }
	public int getX() {
	  return x;
	}
}
```

Selecting <img src="/files/4lkNDIk55EL8087NS6kl" alt="" data-size="line">or `Write Tests` again would now create a complete test.

## Disabling the creation of partial tests

This feature is enabled by default. To disable the creation of partial tests, go to `Diffblue > Change Settings > Partial Test Creation` and uncheck the boxes for the relevant `Allow writing tests ...` options. This will disable the creation of partial tests unless no other tests could be created. If no other tests could be created when selecting <img src="/files/4lkNDIk55EL8087NS6kl" alt="" data-size="line"> or `Write Tests` then Diffblue Cover will create a [skeleton test](/features/cover-plugin/writing-tests/skeleton-tests) with simple inputs to get you started.

<div align="left"><figure><img src="/files/aS22yVWQFX5a1TRn5vhy" alt=""><figcaption></figcaption></figure></div>


# Creating skeleton tests

What are skeleton tests, how to get them and how can they help when using Diffblue Cover?

Skeleton tests simply consist of a call to the method under test, with all variables initialized to `null` or zero, and some comments reminding the user to better populate the "arrange" section and come up with some assertions. They are intended as a helpful starting point for users to write their own tests.

There are two ways of obtaining a skeleton test for a method in Diffblue Cover:

* Click <img src="/files/4lkNDIk55EL8087NS6kl" alt="" data-size="line"> or select `Write Tests` - Diffblue Cover will analyze the method and related classes to write one or more complete tests (or [partial tests](/features/cover-plugin/writing-tests/partial-tests) if this is enabled) exploring the coverage that can be accessed from each method under test. Sometimes this approach is unsuccessful and rather than give you nothing, Diffblue Cover falls back to offering a single skeleton test for the method instead. In this case, the skeleton test provided is disabled, just like any other partial test that is not expected to pass.
* Right-click <img src="/files/4lkNDIk55EL8087NS6kl" alt="" data-size="line"> and select `Write Skeleton Tests` - Diffblue Cover won't analyze your code to write complete tests but instead will only create a single skeleton test for the method. In this case, the skeleton test provided is not disabled as it's assumed that you will complete the test by hand immediately. This can be useful when you need to write a test reproducing a specific scenario and just want some help getting started.

Skeleton tests are intentionally written with all available comments to aid readability, and minimal inlining to ease editing, which means that all test formatting options will be superseded.

For example, consider the method in the following inner class in an outer class, `DatabaseDao`:

```java
public class DatabaseDao {
    public static class Inner {
        private Inner() {
        }

        public void myMethod(Inner inner) {
        }
    }
}
```

Diffblue Cover is unable to test this by default as there doesn't appear to be a way of creating an instance of `Inner` on which to call `myMethod(Inner)`, and so this results in an [`R008`](/features/output-codes/r-reason-codes) output code with some explanation why a full test could not be written. Rather than provide just the output code, Diffblue Cover will offer a skeleton test for the method as follows:

```java
/**
  * Method under test: {@link DatabaseDao.Inner#myMethod(DatabaseDao.Inner)}
  */
@Test
@Disabled("TODO: Complete this test")
void testInnerMyMethod() {
    // TODO: Complete this test.
    //   Reason: R008 Failed to instantiate class under test.
    //   Diffblue Cover was unable to construct an instance of DatabaseDao.Inner.
    //   Add a package-visible constructor or a factory method for the class under test.
    //   If such a method is already present but Diffblue Cover does not find it, it can
    //   be specified using custom rules for inputs:
    //   https://docs.diffblue.com/knowledge-base/cli/custom-inputs/
    //   This can happen because the factory method takes arguments, throws, returns null
    //   or returns a subtype.
    //   See https://diff.blue/R008

    // Arrange
    // TODO: Populate arranged inputs
    DatabaseDao.Inner inner = null;
    DatabaseDao.Inner inner1 = null;

    // Act
    inner.myMethod(inner1);

    // Assert
    // TODO: Add assertions on result
}
```

This skeleton test serves as a helpful illustration of the output code, allowing you to play with your code and better understand why testing the method is difficult, and what could be changed to make it easier. In other cases you will know a way of obtaining an instance to test with, in which case you are well placed to complete the test by hand, choosing useful values for the variables and adding relevant assertions. Alternatively, you may want to "teach" Diffblue Cover how to create useful instances via [Custom Inputs](/features/cover-cli/writing-tests/custom-inputs).


# Covering all enum values

The Diffblue Cover Plugin for IntelliJ can write tests which ensure that all values of an enum are covered when an enum is passed as an argument or returned from a method.

Cover Plugin for IntelliJ can write tests which ensure that all possible values of an `Enum` type are covered by the test suite, when that `Enum` is passed to a method as an argument or is a return value of a method.

## With and without "Cover all enum values"

To understand the difference that the `Cover all enum values` feature makes to created tests, we can write tests on a simple class which takes an `Enum` type as an argument and behaves in different ways depending on that argument's value.

```groovy
public class ErrorFormatter {

  private static final String NON_FATAL_ERROR_TEMPLATE =
      "<p style=\"color:orange\"><em>non-fatal: %s</em></p>";

  private static final String FATAL_ERROR_TEMPLATE =
      "<p style=\"color:red\"><strong>FATAL! %s</strong></p>";

  public String asHtml(ErrorLevel level, String message) {
    switch (level) {
      case INFORMATIONAL:
      case WARNING:
        return String.format(NON_FATAL_ERROR_TEMPLATE, message);
      case FATAL:
        return String.format(FATAL_ERROR_TEMPLATE, message);
      default:
        throw new AssertionError(String.format("Unrecognised error level %s", level));
    }
  }
}
```

Note in particular that the method exhibits the same behavior when the `level` argument is `INFORMATIONAL` or `WARNING`. Two tests that exercise this method by passing those two values to its first argument will therefore cover the same lines of code.

When we write tests on this method with `Cover all enum values` **disabled**, then Cover Plugin creates these tests:

```groovy
@Test
public void testAsHtml() {
  assertEquals("<p style=\"color:orange\"><em>non-fatal: Not all who wander are lost</em></p>",
      (new ErrorFormatter()).asHtml(ErrorLevel.INFORMATIONAL, "Not all who wander are lost"));
  assertEquals("<p style=\"color:red\"><strong>FATAL! Not all who wander are lost</strong></p>",
      (new ErrorFormatter()).asHtml(ErrorLevel.FATAL, "Not all who wander are lost"));
}
```

When we **enable** `Cover all enum values` and write tests again, Cover Plugin creates these tests:

```groovy
@Test
public void testAsHtml() {
  assertEquals("<p style=\"color:orange\"><em>non-fatal: Not all who wander are lost</em></p>",
      (new ErrorFormatter()).asHtml(ErrorLevel.INFORMATIONAL, "Not all who wander are lost"));
  assertEquals("<p style=\"color:orange\"><em>non-fatal: Not all who wander are lost</em></p>",
      (new ErrorFormatter()).asHtml(ErrorLevel.WARNING, "Not all who wander are lost"));
  assertEquals("<p style=\"color:red\"><strong>FATAL! Not all who wander are lost</strong></p>",
      (new ErrorFormatter()).asHtml(ErrorLevel.FATAL, "Not all who wander are lost"));
}
```

With `Cover all enum values` enabled the Cover Plugin creates an extra test, to ensure that both the `INFORMATION` and `WARNING` levels are tested, even though the extra test may not increase the test suite's measured coverage.

## Disable "Cover all enum values"

The `Cover all enum values` feature is enabled by default. To disable, go to `Diffblue > Change Settings > Test Creation` in IntelliJ, and uncheck the `Allow writing tests for all enum values` option.


# Test insertion order

The order of insertion of test methods by Cover Plugin for Intellij

Created test methods are inserted into a test class in the same order that the methods under test appear in the source class (Diffblue Cover does not add a duplicate test if exactly the same test already exists).

### Source Class

```java
public class MyClass {
    public void xyz() {
    }
    public void abc() {
    }
}
```

### Test Class

```java
public class MyClassDiffblueTest {
    public void testXyz() {
    }
    public void testAbc() {
    }
}
```

As illustrated above, the test methods `testAbc` and `testXyz` are not inserted alphabetically into the test class, but instead according to how the methods under test are ordered. Test methods which test the same method are inserted in the order in which they are generated by Cover Plugin.


# Diffblue Sandbox

\
Diffblue Cover writes unit tests by running your code thousands of times as it searches for the best tests that achieve maximum coverage and regression detection. By default, your code is run inside a sandbox which blocks calls with potentially disruptive side-effects such as network, file system, or system changes. However, this can also limit the number of tests that Diffblue Cover can write. Disabling the Diffblue sandbox will allow Cover to run all of your code regardless of side-effects, thereby maximizing coverage. Disabling the sandbox must be done with caution as your code may behave in ways you don't expect (e.g. file system modifications).

Note that if you receive the output code R011 when using Diffblue Cover, this means the method tested performs operations that violate Diffblue Cover’s sandbox policy.

## Sandbox Policy

| Sandbox Policy Enabled (Default)                                                                                                | <p>Sandbox Policy Disabled<br>(Changes Highlighted)</p>                                   |
| ------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Allow access to reflective Java operations (e.g. getting the list of methods of a class).                                       | Allow access to reflective Java operations (e.g. getting the list of methods of a class). |
| Allow setting properties (JUnit needs this during test execution).                                                              | Allow setting properties (JUnit needs this during test execution).                        |
| Allow creating classloaders.                                                                                                    | Allow creating classloaders.                                                              |
| Allow reads of all files.                                                                                                       | Allow reads of all files.                                                                 |
| Allow writes to files created in this session (including deletion).                                                             | **Allow writes of all files (including deletion).**                                       |
| Allow writes of files in `java.io.tmpdir` (including deletion).                                                                 | **Allow writes of all files (including deletion).**                                       |
| Deny writes of files, not created in this session and outside of `java.io.tmpdir` (including deletion).                         | **Allow writes of all files (including deletion).**                                       |
| Deny URL accesses (unless it's a `file://` url with a `GET` request, in which case it's treated like a regular file operation). | **Allow URL accesses.**                                                                   |
| Deny retrieving network information.                                                                                            | **Allow retrieving network information.**                                                 |
| Deny creating Sockets.                                                                                                          | **Allow creating Sockets.**                                                               |
| Deny GUI access.                                                                                                                | **Allow GUI access.**                                                                     |
| Deny `sun.misc.Unsafe`/`sun.misc.*`                                                                                             | **Allow `sun.misc.Unsafe`/`sun.misc.*`**                                                  |
| Deny external process accesses.                                                                                                 | **Allow external process accesses.**                                                      |
| Deny Java Management Extensions (JMX) access.                                                                                   | **Allow Java Management Extensions (JMX) access.**                                        |
| Deny Java Native Interface (JNI) access.                                                                                        | **Allow Java Native Interface (JNI) access.**                                             |
| Deny Smartcards (`java.smartcardio.*`).                                                                                         | **Allow Smartcards (`java.smartcardio.*`).**                                              |
| Deny Printers (`javax.print.*`).                                                                                                | **Allow Printers (`javax.print.*`).**                                                     |
| Deny setting the security manager.                                                                                              | **Allow setting the security manager.**                                                   |
| Deny access control context.                                                                                                    | **Allow access control context.**                                                         |
| Deny Kerberos Authentication access.                                                                                            | **Allow Kerberos Authentication access.**                                                 |
| Deny `System.exit` calls.                                                                                                       | Deny `System.exit` calls.                                                                 |

## Disabling the Diffblue Sandbox

The sandbox policy can be disabled to allow almost all of the operations outlined above (except calling `System.exit`). However, we recommend that you fully familiarize yourself with the information contained in this topic in order to avoid any undesirable effects by allowing these previously denied operations.

To disable the sandbox policy, go to `Diffblue > Change Settings > Sandboxed Environment` in IntelliJ and uncheck `Enable sandboxing`.

<figure><img src="/files/WuplRFoiZEYVJ3mSuVKi" alt=""><figcaption></figcaption></figure>

Note that if you just want to allow a small set of JNI libraries, use the JNI allow list (a comma separated list of JNI library name prefixes) - go to `Diffblue > Change Settings > Sandboxed Environment > Allowed JNI prefixes`.

Also, you may want to consider simply refactoring parts of your code. For example, if you have a method that executes a denied operation but also contains business logic that needs to be verified, you could refactor your code so that any logic that can be executed within the sandbox is contained in a separate, unit-testable method - this ensures the business logic is tested and consequently increases code coverage.

## Harmful Example

Let's look at an example of a denied operation and what *could* happen if it were allowed. One of the operations prevented by default is accessing files outside of the temp directory (specified by `java.io.tmpdir`). We further restrict this by allowing only *writing* to newly created files. The `root` parameter may end up pointing to a real directory on your system (it could be given any value, such as `/`, `C:\`, `/home/User/`), and then be executed, removing all the files contained within that directory along with the directory itself. With the *default* policy in place, trying to write tests for this method would result in an [R011](/features/output-codes/r-reason-codes) output code.

```java
public class Harmful {
    public void deleteRecursively(final Path root) {
        final File[] contents = directoryToBeDeleted.listFiles();
        if (contents != null) {
            for (final File file : contents) {
                deleteRecursively(file);
            }
        }
        return directoryToBeDeleted.delete();
    }
}
```

## Operations

The tables below outline the denied operations (Diffblue sandbox enabled) and explains what can happen (in the worst case) if they are allowed (Diffblue sandbox disabled). Note that:

* The exact nature of the risk is heavily dependent on the application being analyzed and can't be predicted ahead of time. If the application being analyzed is a web-based application in an automated pipeline that has no access to production systems, the risk of experiencing many of the adverse effects mentioned below is relatively low.
* The impact of the Diffblue sandbox policy is not restricted to just the method, but methods that call these methods, and so on.

### I/O Operation

<table data-full-width="true"><thead><tr><th width="136">Operation</th><th>Allowed by Default?</th><th>Change with "Disable Sandbox"</th><th>Possible Effect if Allowed</th></tr></thead><tbody><tr><td>Networking</td><td>No</td><td>Allowed</td><td>Unexpected network traffic, data loss on remote machines, instability in unit tests.</td></tr><tr><td>FileIO</td><td>Read all files, write new files.</td><td>Read all files, write all files.</td><td>Data loss on the machine where Cover is running, instability in unit tests.</td></tr><tr><td>TmpFileIO</td><td>Read all files, write new files.</td><td>Read all files, write all files.</td><td>Unnecessary disk space is consumed, instability in unit tests.</td></tr></tbody></table>

* Data loss is likely to occur if methods (like a hypothetical `delete` method in a typical web application) are invoked and happen to have access to live credentials (e.g. production or test environments).
* Likewise, unexpected network traffic can occur if the application makes raw network requests to servers.
* Disk space may be consumed because the application may not clean up temporary files.

### Java Libraries

<table data-full-width="true"><thead><tr><th width="206.5">Library</th><th width="243">Allowed by Default?</th><th width="273">Change with "Disable Sandbox"</th><th>Possible Effect if Allowed</th></tr></thead><tbody><tr><td>GUI (Swing/AWT)</td><td>No, <code>java.awt.headless</code> is set to <code>true</code></td><td>Allowed, <code>java.awt.headless</code> is set to <code>false</code></td><td>N/A</td></tr><tr><td><code>sun.misc.*</code></td><td>No</td><td>Allowed</td><td>Instability of tests across JVM vendors and operating systems.</td></tr><tr><td><code>sun.misc.Unsafe</code></td><td>No</td><td>Allowed</td><td>Unintended side effects across unit tests in a class, or test suite.</td></tr></tbody></table>

* Trying to write unit tests for methods that invoke GUIs is difficult. In those cases, the `java.awt.headless` property is usually set to `true` to disable those GUI components. If you require tests for the logic behind the GUIs, it's better to refactor the code to allow that logic to be tested independently of the GUI.
* The `sun.misc.*` packages provide very low level access to fundamental system operations and do not form a part of the public interface. Because of the very low level access, we deem these operations unsafe due to the risk of unintended side effects.
* Furthermore, the following is taken from the published Oracle [FAQ](https://www.oracle.com/java/technologies/faq-sun-packages.html) regarding the use of these packages.

> The `sun.*` packages are not part of the supported, public interface.
>
> A Java program that directly calls into `sun.*` packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform.
>
> Each company that implements the Java platform will do so in their own private way. The classes in `sun.*` are present in the JDK to support Oracle's implementation of the Java platform: the `sun.*` classes are what make the Java platform classes work "under the covers" for Oracle's JDK. These classes will not in general be present on another vendor's Java platform. If your Java program asks for a class `"sun.package.Foo"` by name, it may fail with `ClassNotFoundError`, and you will have lost a major advantage of developing in Java.
>
> Technically, nothing prevents your program from calling into `sun.*` by name. From one release to another, these classes may be removed, or they may be moved from one package to another, and it's fairly likely that their interface (method names and signatures) will change. (From Oracle's point of view, since we are committed to maintaining the Java platform, we need to be able to change `sun.*` to refine and enhance the platform.) In this case, even if you are willing to run only on Oracle's implementation, you run the risk of a new version of the implementation breaking your program.
>
> In general, writing java programs that rely on `sun.*` is risky: those classes are not portable, and are not supported.

### System Operations

<table data-full-width="true"><thead><tr><th width="180">Operation</th><th width="189.25">Allowed by Default?</th><th width="274">Change with "Disable Sandbox"</th><th>Possible Effect if Allowed</th></tr></thead><tbody><tr><td>External Processes</td><td>No</td><td>Allowed</td><td>Instability of unit tests, random behavior of other processes.</td></tr><tr><td>JMX</td><td>No</td><td>Allowed</td><td>Instability of unit tests, random behavior of JMX enabled beans/services/etc.</td></tr><tr><td>JNI</td><td>No, except JNI allow list - see below.</td><td>Allowed</td><td>Tests won't generate coverage for the native code.</td></tr><tr><td><code>System.exit</code></td><td>No</td><td>No</td><td>Causes the analysis service JVM to exit and would increase in the occurrence of R024/R025 output codes (from Diffblue Cover).</td></tr></tbody></table>

**\*** Note that if the Diffblue sandbox policy is blocking access to a JNI library that you believe to be safe to use, then you can add it to the JNI allow list (a comma separated list of JNI library name prefixes can be used) - go to `Diffblue > Change Settings > Sandboxed Environment > Allowed JNI prefixes`.

### Peripherals

Generally, these operations require access to specific hardware which may or may not be present. Because this can't be determined beforehand, unit tests for methods using these APIs would be inherently unstable.

<table data-full-width="true"><thead><tr><th width="167.4">Peripheral</th><th width="183">Allowed by Default?</th><th width="271">Change with "Disable Sandbox"</th><th>Possible Effect if Allowed</th></tr></thead><tbody><tr><td>Smartcards</td><td>No</td><td>Allowed</td><td>Corruption of data on the smartcards.</td></tr><tr><td>Printing</td><td>No</td><td>Allowed</td><td>Print jobs are submitted to configured printers.</td></tr></tbody></table>

### Security

<table data-full-width="true"><thead><tr><th width="169">Security</th><th width="185">Allowed by Default?</th><th width="267">Change with "Disable Sandbox"</th><th>Possible Effect if Allowed</th></tr></thead><tbody><tr><td>Setting security manager</td><td>No</td><td>Allowed</td><td>Unit tests won't be created or verified.</td></tr><tr><td>Create access control context</td><td>No</td><td>Allowed</td><td>Attempts to bypass sandbox will be allowed.</td></tr><tr><td>Kerberos Authentication</td><td>No</td><td>Allowed</td><td>Unintended side-effects with Kerberos systems.</td></tr></tbody></table>


# Environment Check Cache

A part of writing tests is to determine whether the environment is configured correctly. This environment check is performed immediately before writing tests and can take some time.

Since the environment does not change that often, Cover will cache the results of a check and reuse the results in subsequent write test operations. This helps to deliver tests faster.

If some of the properties of the environment change, the cache will be automatically invalidated and Cover will run a new check the next time tests are written.

## Clearing the Environment Check Cache

It is possible that occasionally changes to the environment are not detected by Cover and the cache will be used when it shouldn't be.

In this case, an error will be shown when writing tests. To clear the cache and force Cover to check the environment either:

* Select the `Clear Environment Check Cache` option from the main Diffblue menu
* Press the `Clear Environment Check` Cache button in the Diffblue Cover tool panel

The next write tests operation will then check the environment for changes.


# Project configuration

Before using Cover Plugin to write tests, your project must meet the following general requirements:

* Java 8, 11, 17, or 21 compatible source code, or Kotlin source code.
* Maven 3.2.5+ or Gradle 4.9+ build tools.
* The project must compile and run with no failing unit tests.
* All associated dependencies have been added, including JUnit or TestNG testing frameworks.

Also, Diffblue Cover requires that the system environment (hardware, operating system, network connectivity, Java installation) as well as the project environment (build tooling, dependencies, presence of artifacts, existing unit tests) meet the minimum requirements as detailed in [Specs & Reqs](/get-started/specs-and-reqs). Cover Plugin will perform an environment check before analysis begins to ensure that the requirements are met - if there are any issues, these will be reported via the Diffblue Cover panel in IntelliJ using E (Environment) [Output Codes](/features/output-codes).

{% hint style="info" %}
Note that you can run `dcover create --preflight` (using [Diffblue Cover CLI](/get-started/get-started/get-started-cover-cli)) to check the Cover prerequisites for your project, without performing any other actions.
{% endhint %}


# General dependencies

Dependencies required for running tests should be in the project configuration. Additional libraries may also be necessary depending on the project under test. For version information, see [Specs & Reqs](/get-started/specs-and-reqs).

<table data-full-width="false"><thead><tr><th width="309">Dependency</th><th>Description</th></tr></thead><tbody><tr><td>Test Framework</td><td>See <a data-mention href="/pages/ti2uzF1sbd83PH279xuq">/pages/ti2uzF1sbd83PH279xuq</a>.</td></tr><tr><td>Surefire Plugin<br><code>org.apache.maven.plugins:</code><br><code>maven-surefire-plugin</code></td><td>When using Maven and junit-jupiter-engine.</td></tr><tr><td>JUnit Launcher<br><code>org.junit.platform:</code><br><code>junit-platform-launcher</code>)</td><td>When using junit-jupiter-engine, unless using Maven, Spring, or Spring Boot.</td></tr><tr><td><p>Spring Boot Test</p><p><code>org.springframework:</code><br><code>spring-boot-test</code></p></td><td>When using Spring Boot ( <code>org.springframework:spring-boot</code>).</td></tr><tr><td>Spring Test<br><code>org.springframework:</code><br><code>spring-test</code></td><td>When using Spring ( <code>org.springframework:spring-core</code>) unless using Spring Boot.</td></tr><tr><td>Mockito<code>org.mockito:</code><br><code>mockito-core</code></td><td>For mocking using Mockito.</td></tr></tbody></table>

Other dependencies listed below may be needed, if they are transitive dependencies of your project. If one of these dependencies is required but missing, tests will be generated for some classes but not others. A message will appear in the console output indicating a missing dependency. For version information, see [Specs & Reqs](/get-started/specs-and-reqs).

| Dependency                                                                                                                        |
| --------------------------------------------------------------------------------------------------------------------------------- |
| <p>Java Servlet API</p><p><code>javax.servlet:javax.servlet-api</code> or<br><code>jakarta.servlet:jakarta.servlet-api</code></p> |
| <p>JSR107 API and SPI</p><p><code>javax.cache:cache-api</code></p>                                                                |
| <p>Spring Boot Starter Test</p><p><code>org.springframework.boot:spring-boot-starter-test</code></p>                              |
| <p>Spring Security Config</p><p><code>org.springframework.security:spring-security-config</code></p>                              |
| <p>Spring Web MVC</p><p><code>org.springframework:spring-webmvc</code></p>                                                        |


# Test framework dependencies

Tests created by Diffblue Cover make use of a testing framework, namely one of JUnit 4, JUnit Jupiter, or TestNG - these frameworks are included in the required dependencies below. These dependencies are available from the Maven Central Repository. To add it, follow the guide relevant to your build tool.

## Maven

Check whether or not the test framework dependencies are already in your Maven project. If not, follow the instructions below to add it:

1. Edit the `pom.xml`
2. Add the [surefire plugin](https://maven.apache.org/surefire/maven-surefire-plugin/index.html) to the `build plugins` section

```
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>3.5.4</version>
        </plugin>
    </plugins>
</build>
```

{% hint style="info" %}
With recent versions of surefire, it is not necessary to specify any `plugin dependencies` for the specific testing framework being used; surefire will detect the versions specified in the `project dependencies` section as specified below.
{% endhint %}

{% hint style="info" %}
Explicitly specifying a testing framework in the `plugin dependencies` (e.g. to override the provider) can result in a reduced capability in the surefire plugin. In some cases, this can prevent Cover from grouping tests correctly which affects coverage calculations.
{% endhint %}

1. Add JUnit or TestNG to the `dependencies` section:

**For JUnit 4:**

```
<dependencies>
  [...]
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.13.2</version>
      <scope>test</scope>
    </dependency>
  [...]
</dependencies>
```

**For JUnit Jupiter 5:**

```
<dependencies>
    [...]
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter-engine</artifactId>
        <version>5.9.1</version>
        <scope>test</scope>
    </dependency>
    [...]
</dependencies>
```

**For TestNG:**

```
<dependencies>
  [...]
    <dependency>
      <groupId>org.testng</groupId>
      <artifactId>testng</artifactId>
      <version>6.9.8</version>
      <scope>test</scope>
    </dependency>
  [...]
</dependencies>
```

## Gradle

Check whether or not the test framework dependencies are already in your Gradle project. If not, follow the instructions below to add it:

1. Edit the build script (`build.gradle` or `build.gradle.kts`).
2. Add Maven to the `repositories` section.

   ```groovy
    repositories {
        mavenCentral()
    }
   ```
3. Add JUnit or TestNG to the `dependencies` section:

**For JUnit 4:**

{% tabs %}
{% tab title="GROOVY" %}

```groovy
 dependencies {
     testCompile group: 'junit', name: 'junit', version: '4.13.2'
 }
```

{% endtab %}

{% tab title="KOTLIN" %}

```kotlin
 dependencies {
     testCompile("junit:junit:4.13.2")
 }
```

{% endtab %}
{% endtabs %}

**For JUnit Jupiter 5:**

{% tabs %}
{% tab title="GROOVY" %}

```groovy
 dependencies {
     testCompile group: 'org.junit.jupiter', name: 'junit-jupiter', version: '5.8.0'
 }
```

{% endtab %}

{% tab title="KOTLIN" %}

```kotlin
 dependencies {
     testCompile("org.junit.jupiter:junit-jupiter:5.8.0")
 }
```

{% endtab %}
{% endtabs %}

**For TestNG:**

{% tabs %}
{% tab title="GROOVY" %}

```groovy
 dependencies {
     testCompile group: 'org.testng', name: 'testng', version: '7.8.0'
 }
```

{% endtab %}

{% tab title="KOTLIN" %}

```kotlin
 dependencies {
     testCompile("org.testng:testng:7.8.0")
 }
```

{% endtab %}
{% endtabs %}

{% hint style="info" %}
The versions specified are the latest at the time of writing. Please use the latest versions available for the best results
{% endhint %}

## Run the tests

Choose one of the new test classes in the project explorer, right-click and select `'Run ClassnameTest'`. The IDE will then show the results of the run.


# Cover Plugin settings

To modify the Diffblue Cover settings in IntelliJ, go to `Diffblue > Change Settings` and update as needed.

<figure><img src="/files/POewy4HlLEqHd24DVtEW" alt=""><figcaption></figcaption></figure>

* **Test Framework**: Select the test framework used for your project - `JUnit 4`, `JUnit 5`, `TestNG`, or `Auto-Detect`.
* **Test Creation**:
  * Enable/disable the use of `Cover all enum values` (ensure all enum values are covered, when an enum is used as a method argument or return value) - see [Covering all enum values](/features/cover-plugin/writing-tests/covering-all-enum-values).
  * Enable/disable the use of `Ignore existing coverage` (default: off) - see [Test Coverage Optimizations](/features/cover-cli/writing-tests/test-coverage-optimizations)
* **Partial Test Creation**: Enable/disable the creation of partial tests for specific scenarios - see [Creating partial tests](/features/cover-plugin/writing-tests/partial-tests).
* **Test Review**: Enable manual review and editing of tests before they are added to your codebase - see [Test Review](/features/cover-plugin/writing-tests/test-review)
* **Test Naming**: Define the test class and test method naming conventions used for tests written by Diffblue Cover - see [Test Naming](/features/cover-plugin/cover-plugin-settings/test-naming).
* **Test Formatting**: Select the test style or specific formatting options for tests written by Diffblue Cover - see [Test Formatting](/features/cover-plugin/cover-plugin-settings/test-formatting).
* **Spring**: Set your Spring configuration options (mocking, Spring contexts, and active profiles) - see [Spring configuration options](/features/cover-plugin/cover-plugin-settings/spring-configuration-options).
* **Method Annotations**: Suppress compiler warnings for test methods written by Diffblue Cover - see [Method Annotations](/features/cover-plugin/cover-plugin-settings/method-annotations). This is especially useful when using SonarQube - see [Using SonarQube with Cover Plugin](/features/cover-plugin/cover-plugin-admin/using-sonarqube-with-cover-plugin).
* **Sandboxed Environment**: Enable (default) or disable the Diffblue Sandbox and/or define a list of allowed JNI libraries (if needed) - see [Diffblue Sandbox](/features/cover-plugin/writing-tests/diffblue-sandbox).

{% hint style="info" %}
In addition to these settings, the host environment can be configured in several ways which are described in [Environment Configuration](/features/cover-cli/environment-configuration)
{% endhint %}


# Test Naming

Instructions on how to define the naming system used for tests generated by the Cover Plugin for IntelliJ.

Test classes and methods created by Diffblue Cover are named after the class and methods under test using configurable templates. To change the naming, go to `Diffblue > Change Settings` in IntelliJ and update the `Test Naming` section as needed.

<figure><img src="/files/LeeI25sMz8ck3ESv3FR3" alt=""><figcaption></figcaption></figure>

## Class Name Template

**Description:** Used to define the test class naming convention for tests written by Diffblue Cover. The `${CLASS}` variable will be substituted with the name of the class under test.

**Default:** `${CLASS}DiffblueTest`

**Example:** `${CLASS}CreatedTest`

```java
public class UserAccessCreatedTest {

    public String currentUser;

    ...
}
```

{% hint style="info" %}
Merge mode is enabled by default in the IntelliJ plugin. However, the default template `${CLASS}DiffblueTest` keeps generated tests in separate files.

To take advantage of merge mode, change the class name template to match your existing test naming conventions (e.g., `${CLASS}Test`). This allows generated tests to merge into your existing test classes.

See [Merge Mode](/features/cover-cli/writing-tests/merge-mode) for more information about merge mode.
{% endhint %}

## Method Name Template

**Description:** Used to define the test method naming convention for tests written by Diffblue Cover. The following variables can be used:

* `${INNER}` - substituted with the name of the inner class for the method under test. If there's no inner class this will be an empty string.
* `${UNIT}` - usually substituted with the name of the method under test. Where the unit under test comprises multiple methods (getters and setters, equals and hash code) the more general unit under test name is used.
* `${METHOD}` - substituted with the name of the first method under test, typically the only method under test. To avoid duplication, do not use `${UNIT}` and `${METHOD}` together.
* `${GIVEN}` - substituted with a summary of the conditions before testing, or else blank.
* `${WHEN}` - substituted with a summary of the conditions under test, or else blank.
* `${THEN}` - substituted with a summary of the test's consequences, or else blank.
* `${_}` - substituted with an underscore, or blank if there are no values to separate.

**Default:** `test${INNER}${UNIT}${_}${GIVEN}${_}${WHEN}${_}${THEN}`

**Example:** `aitest${INNER}${UNIT}`

```java
@Test
public void aitestGettersAndSetters() {
    // Arrange
    ComponentPojo componentPojo = new ComponentPojo();

    // Act
    componentPojo.setName("Name");
    componentPojo.setSize(3);
    String actualName = componentPojo.getName();
    // Assert that nothing has changed
    assertEquals("Name", actualName);
    assertEquals(3, componentPojo.getSize());
}

@Test
public void aitestEqualsAndHashCode() {
    // Arrange
    DoubleArgumentType doubleArgResult = DoubleArgumentType.doubleArg(10.0d, 10.0d);

    // Act and Assert
    assertEquals(doubleArgResult, doubleArgResult);
    int expectedHashCodeResult = doubleArgResult.hashCode();
    assertEquals(expectedHashCodeResult, doubleArgResult.hashCode());
}
```

## Descriptive Test Names

Descriptive `${GIVEN}` , `${WHEN}` and `${THEN}` summaries are populated when disambiguating multiple tests for the same method under test, and are added to the test method name up to a maximum of 80 characters. When descriptive test names are enabled they are additionally used to provide improved javadoc comments, and to provider clearer test display names when the test framework supports it.

```java
/**
 * Test {@link BaseEntity#isNew()}; given BaseEntity Id one; then returns false.
 * <p>
 * Method under test: {@link BaseEntity#isNew()}
 */
@Test
@DisplayName("Test isNew(); given BaseEntity Id one; then returns false")
void testIsNew_givenBaseEntityIdOne_thenReturnsFalse() {
	// Arrange
	BaseEntity baseEntity = new BaseEntity();
	baseEntity.setId(1);

	// Act and Assert
	assertFalse(baseEntity.isNew());
}

/**
 * Test {@link BaseEntity#isNew()}; given BaseEntity; then returns true.
 * <p>
 * Method under test: {@link BaseEntity#isNew()}
 */
@Test
@DisplayName("Test isNew(); given BaseEntity; then returns true")
void testIsNew_givenBaseEntity_thenReturnsTrue() {
	// Arrange, Act and Assert
	assertTrue((new BaseEntity()).isNew());
}
```

When `${UNIT}` is describes a single method under test that has overloads then the method under test's arguments are additionally described.

```java
/**
 * Test {@link Owner#getPet(String)} with name.
 * <p>
 * Method under test: {@link Owner#getPet(String)}
 */
@Test
@DisplayName("Test getPet(String) with name")
void testGetPetWithName() {
	// Arrange, Act and Assert
	assertNull((new Owner()).getPet("Bella"));
}

/**
 * Test {@link Owner#getPet(String, boolean)} with name, ignoreNew.
 * <p>
 * Method under test: {@link Owner#getPet(String, boolean)}
 */
@Test
@DisplayName("Test getPet(String,boolean) with name, ignoreNew")
void testGetPetWithNameIgnoreNew() {
	// Arrange, Act and Assert
	assertNull((new Owner()).getPet("Bella", true));
}
```

Descriptive test names are enabled by default but can be disabled via the "Descriptive Test Names" setting.

## Numeric Disambiguation

Disambiguation between tests of the same name is performed automatically using sequential numbering:

```java
@Test
public void testAppendTitle() {
    ...
}

@Test
public void testAppendTitle2() {
    ...
}
```


# Test Formatting

The format of tests produced by Cover Plugin for IntelliJ can be configured via the "Test Formatting Options" within settings.

To configure the format of tests written by Cover Plugin, go to `Diffblue > Change Settings > Test Formatting` in IntelliJ.

## IntelliJ Code Style Formatting Compatibility

It's important to note that the formatting of tests produced by Cover Plugin for IntelliJ, especially regarding indentation and other style settings, is in line with your current IntelliJ Code Style configurations. This ensures that the generated tests adhere to the code style settings you've set up in your IDE. If you experience formatting conflicts with other tools, such as Spotless, you might need to align your IntelliJ code style settings with those tools to maintain consistency.

You are able to turn off IntelliJ Code Style formatting through the Diffblue settings menu "Apply code style formatting". With this setting turned off tests will be formatted in a way that will match the output of Cover CLI.

<figure><img src="/files/2jOOky0sbJPFUKqgh9Lw" alt=""><figcaption></figcaption></figure>


# Spring configuration options

Spring configuration options for Diffblue Cover Plugin for IntelliJ.

To set your Spring configuration options for Cover Plugin go to `Diffblue > Change Settings > Spring` in IntelliJ.

## Mocking in Spring integration tests

Check the `Enable integration tests` option to limit mocking for Spring projects to Repository dependencies only - Spring handles the rest directly. If this option is not selected then mocking may be implemented for a wider scope of dependencies.

* Spring Repositories are classes implementing `org.springframework.data.repository.Repository` or those annotated with `org.springframework.stereotype.Repository`.
* This option is not applied when creating tests for `@Controller` classes.

## Spring contexts

Check the `Use Spring contexts` option to enable Spring contexts for dependency injection in tests written by Diffblue Cover.

## Spring Boot Tests

Check the `Use Spring Boot to write tests` option for dependency injection using, amongst the others,`@MockBean`. If this option is not enabled Cover will instead fall back to other dependency injection mechanisms for tests such as Mockito's `@InjectMocks` and `@Mock`. This option may be useful depending on whether or not a Spring context needs to be loaded for a particular unit test suite.

**Note:** This functionality is in Beta stage, hence there could be cases where some inconsistencies and limitations might still be present.

## Active profiles

Use the `Active Profiles` text box to specify one or more Spring profiles to activate while writing tests (comma separated list). If no profiles are defined, Cover will automatically use the `test` profile (if available), otherwise the default Spring profile will be used.


# Method Annotations

To suppress compiler warnings for test methods written by Diffblue Cover, go to `Diffblue > Change Settings > Method Annotations` and update the `Warnings to suppress` list, as needed. The warnings or warning types defined here will be added to all test methods written by Diffblue Cover (as detailed below) using the `@SuppressWarnings` code annotation. This is especially useful when using SonarQube - see [Using SonarQube with Cover Plugin](/features/cover-plugin/cover-plugin-admin/using-sonarqube-with-cover-plugin).

<div align="left"><figure><img src="/files/1HwXeY0DvWDuA8gPTaLo" alt="" width="563"><figcaption></figcaption></figure></div>

**Example - all:** `all`

Suppresses all warnings - adds the code annotation `@SuppressWarnings({"all"})`\`

**Example - types:** `unused,raw-types`

Suppresses one or more "warning types" - this example adds the code annotation `@SuppressWarnings({"unused","raw-types"})`

**Example - specific:** `java:S1161`

Suppresses one or more specific warnings (using warning codes) - this example, adds the code annotation `@SuppressWarnings({"java:S1161"}`


# Test Directory

How to locate the tests created by Cover Plugin for IntelliJ, within your project.

The tests created by Cover Plugin for IntelliJ will be placed in a location within the project according to the following:

1. If a test source directory (e.g `src/test/java`) exists in the current project module, Cover Plugin will add the tests there.
2. If no existing test source directory could be found for the current project module, Cover Plugin will add tests to `src/test/java` in the same module as the class for which tests are written (`project_root/module/src/test/java`).

**We recommend always explicitly creating a test source directory** `src/test/java` in the relevant module so that Cover Plugin knows where to put new test classes.

Cover Plugin does not add a duplicate test if exactly the same test already exists.

### Override Test Directory

If you have multiple test source directories set up for a module, you can use the `Override Test Directory` setting to ensure that Cover Plugin creates tests in your preferred directory - go to `Diffblue > Change Settings` and expand the `Diffblue Cover` settings menu on the left. Note that this is a project setting.

For example, you may have a Gradle configuration similar to the following:

```groovy
sourceSets {
    test {
        java {
            srcDir "src/test/java"
            srcDir "src/diffblueTest/java"
        }
    }
}
```

Use the `Override Test Directory` setting to make sure that Cover Plugin adds tests to the `src/diffblueTest/java` directory:

<figure><img src="/files/VngczLASineBhxdTSJzR" alt="" width="563"><figcaption></figcaption></figure>


# Reset Cover Plugin settings

How to reset Cover Plugin to its default settings.

## Cover Plugin Settings

To reset Cover Plugin Settings:

1. Open the Cover Settings panel in the IntelliJ IDE.
2. At the bottom of the Test Creation Tab, select the 'Restore Test Creation Settings' button to reset settings.\\

   <figure><img src="/files/65Nnp1WkkMgz67pqqwpO" alt=""><figcaption><p>Note: The 'Restore Default Test Creation Settings' button will not be selectable if the currently applied settings are already default.</p></figcaption></figure>

## Project settings

To remove any project specific settings:

1. Open the project in the IntelliJ IDE and navigate to `.idea` folder in the project.
2. Delete the `CoverSettingsProjectConfig.xml` file, if present.


# Cover Plugin admin

Common Cover Plugin admin:

* [**Telemetry Config**](/features/cover-plugin/cover-plugin-admin/telemetry): Enable/disable and configure telemetry for Cover Plugin.
* [**Memory Management**](/features/cover-plugin/cover-plugin-admin/memory-management): Tips for memory management, including how to increase the amount of memory that Diffblue Cover has access to.
* [**SonarQube**](/features/cover-plugin/cover-plugin-admin/using-sonarqube-with-cover-plugin): Suppress warnings and reduce reported "code smells" in SonarQube.
* [**Log Files**](/features/cover-plugin/cover-plugin-admin/log-files): User and Support Log Files.
* [**Troubleshooting**](/features/cover-plugin/cover-plugin-admin/troubleshooting): Help with a few common issues that you may encounter.


# Core Maintenance

Install, Update, Disable, Re-Enable, and Uninstall Cover Plugin

## Install

#### 1. Install Diffblue Cover Plugin for IntelliJ

{% tabs %}
{% tab title="From IntelliJ IDE" %}

1. In the IntelliJ IDE, open the `Plugins` menu - either `File > Settings > Plugins` (Windows/Linux) or `IntelliJ IDEA > Preferences > Plugins` (macOS).
2. Select the `Marketplace` tab, search for `Diffblue`, and click `Install`. Your plugin will now be downloaded and installed.
3. When prompted, click `Restart IDE` to complete the install.

<div align="left"><figure><img src="/files/yZdmQKOSfbjavEKeQT2C" alt="" width="563"><figcaption></figcaption></figure></div>
{% endtab %}

{% tab title="From a ZIP Archive" %}

1. Download the Diffblue Cover Plugin for IntelliJ as a `.zip` bundle from:\
   \
   \&#xNAN;**-** The Diffblue website - [Free Community Edition](https://www.diffblue.com/community-edition/download) or [Free Trial](https://www.diffblue.com/try-cover) versions.\
   \
   \&#xNAN;**-** The [JetBrains Marketplace](https://plugins.jetbrains.com/) (IntelliJ Plugin Marketplace).\
   \
   \&#xNAN;**-** The link sent to you via your Diffblue Cover welcome email.\
   \
   \&#xNAN;**-** Your organization's internal file/app store.\\
2. In the IntelliJ IDE, open the `Plugins` menu - either `File > Settings > Plugins` (Windows/Linux) or `IntelliJ IDEA > Preferences > Plugins` (macOS).
3. Click on the cog icon next to the `Installed` tab and select `Install Plugin from Disk...`. Navigate to the location of the plugin, select the zip file, and click `OK`.
4. When prompted, click `Restart IDE` to complete the install.

<div align="left"><figure><img src="/files/ycvubmiRG7vxeLQ2vK8C" alt="" width="266"><figcaption></figcaption></figure></div>
{% endtab %}
{% endtabs %}

#### 2. Apply a license

Once IntelliJ has restarted, you'll be prompted for your license key (provided in your welcome email or by your organization) to activate the plugin. Alternatively, the license can be activated at any time from the IntelliJ toolbar `Diffblue > Activate License`. Diffblue Cover requires a remote license check with the Diffblue licensing server each time it's used. For help troubleshooting license keys, network connections, and proxy server settings, see [Licensing](/get-started/licensing). Note that:

* Applying a license provides access to the Teams and Enterprise Editions of Diffblue Cover.
* Cover Plugin Community Edition is free to use but does require product verification to activate your perpetual license.
* Offline license activation is available with the Diffblue Cover Enterprise Edition only. This can only be done through the CLI.
* See [Cover Editions](/updates-and-upgrades/cover-editions) and [Licensing](/get-started/licensing) for more details.

<div align="left"><figure><img src="/files/UH5v6XEaJhuFUIstBSwa" alt="" width="375"><figcaption></figcaption></figure></div>

#### 3. Ensure VM is correctly set up

If not already using google-java-format please check and upgrade your VM options in IntelliJ following the guidance here. [Ensure formatter compatibility](/features/cover-plugin/cover-plugin-admin/ensure-formatter-compatibility)

## Update, Disable, Enable, Uninstall

1. In IntelliJ, go to `File > Settings > Plugins` (Windows/Linux) or `IntelliJ IDEA > Preferences > Plugins` (macOS) and highlight the Diffblue Plugin:

* Click `Update` in the details panel to update to the latest version. Note that updating Cover Plugin may take a few minutes to complete and will require an IDE restart - you won't be able to create any tests for your projects while the update is progressing.
* Select and click `Disable` from the drop down menu in the details panel to temporarily disable the plugin.
* Select and click `Enable` from the drop down menu in the details panel to re-enable the plugin.
* Select and click `Uninstall` from the drop down menu in the details panel to uninstall the plugin.

2. When you're ready, click `Restart IDE` to complete the update.


# Ensure formatter compatibility

Settings required to ensure compatibility with google-java-format in the Plugin

Diffblue Cover IntelliJ Plugin uses google-java-format to format your test suite.

Cover will recognise (E166) and require you to set up your IntelliJ VM with the following options to ensure formatter can run.

Please follow the steps at:

{% embed url="<https://www.jetbrains.com/help/idea/tuning-the-ide.html#configure-jvm-options>" %}

and add the following options, then restart your IntelliJ IDE for them to take effect.

```
--add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED
```


# Cover Plugin toolbar menu

The Cover Plugin toolbar menu provides many actions for the user:

* Write tests & Write Skeleton tests. For more information see [Discover Diffblue Cover](/).
* Change Settings. For more information see [Cover Plugin settings](/features/cover-plugin/cover-plugin-settings).
* Clear Environment Check Cache. For more information see [Environment Check Cache](/features/cover-plugin/writing-tests/environment-check-cache)
* View and Activate License. For more information see [Core Maintenance](/features/cover-plugin/cover-plugin-admin/core-maintenance)
* View documentation. This will load [docs.diffblue.com](https://docs.diffblue.com/)
* Community Support Forum. This will load [forum.diffblue.com](https://forum.diffblue.com/)
* Submit Feedback. This will load a feedback form.
* Getting Started. This will launch the Getting Started experience which will take you through the essentials of using the plugin.
* What's New. This will load the latest release news and updates. See [What's new](/updates-and-upgrades/whats-new).

<figure><img src="/files/9bFbXoeyXue9eCQLil8S" alt=""><figcaption></figcaption></figure>


# Cover Plugin status bar widget

The Cover Plugin status bar widget provides a quick view to see your current usage, as well as easy access to:

* View License Info (to see more details about your license)
* Activate License (to activate a new license - including upgrading to a new license)
* Upgrade license (to find out more about license plans and purchase an upgraded license)

<figure><img src="/files/c1F1a8nKoBud3RKXZv5g" alt=""><figcaption></figcaption></figure>


# Telemetry

Telemetry (usage data collection) in Cover Plugin for IntelliJ.

Diffblue Cover captures telemetry (usage) data to help improve Cover services and features. Data is sent to the following endpoints:

* **Diffblue** - Telemetry data is sent to Diffblue by default.
* **Cover Reports** - Telemetry data can be sent to your Cover Reports instance (if required), allowing you to monitor Diffblue Cover usage across your organization.

Further information on our data collection and policies is provided in the [Diffblue Privacy Notice](/legal/diffblue-legal/privacy-notice).

## Configure telemetry

Telemetry can be configured (if required) using environment variables, and/or a properties file, on the host machine (where Diffblue Cover is being used). Note that these configuration settings apply to Cover Plugin **and** Cover CLI.

* Environment variables always take priority and is the recommended method for configuring telemetry - variables listed below.
* If you use a properties file, create a `telemetry.properties` file in the home directory under the `.diffblue` folder (for example, `/users/joeblogs/.diffblue/telemetry.properties`) and define one or more of the properties listed below.
* If an individual environment variable or property is not found, the default value will be used.

<table data-full-width="false"><thead><tr><th width="239">Environment variable</th><th width="138">Property</th><th width="263">Description</th><th width="131">Default</th></tr></thead><tbody><tr><td><code>DIFFBLUE_TELEMETRY_</code><br><code>EXTERNAL_ENABLED</code></td><td><p><code>telemetry.</code></p><p><code>external.</code></p><p><code>enabled</code></p></td><td>Enable (<code>true</code>) or disable (<code>false</code>) telemetry data for Diffblue. <strong>*</strong></td><td><code>true</code></td></tr><tr><td><code>DIFFBLUE_TELEMETRY_</code><br><code>REPORTS_ENABLED</code></td><td><p><code>telemetry.</code></p><p><code>reports.</code></p><p><code>enabled</code></p></td><td>Enable (<code>true</code>) or disable (<code>false</code>) telemetry data for Cover Reports. <strong>**</strong></td><td><code>false</code></td></tr><tr><td><code>DIFFBLUE_TELEMETRY_</code><br><code>REPORTS_HOSTNAME</code></td><td><p><code>telemetry.</code></p><p><code>reports.</code></p><p><code>hostname</code></p></td><td>Hostname of your Cover Reports server. <strong>**</strong></td><td><code>localhost</code></td></tr><tr><td><code>DIFFBLUE_TELEMETRY_</code><br><code>REPORTS_PORT</code></td><td><p><code>telemetry.</code></p><p><code>reports.</code></p><p><code>port</code></p></td><td>Port number of your Cover Reports instance <strong>**</strong></td><td><code>8080</code></td></tr><tr><td><code>DIFFBLUE_TELEMETRY_</code><br><code>REPORTS_SCHEME</code></td><td><p><code>telemetry.</code></p><p><code>reports.</code></p><p><code>scheme</code></p></td><td>Protocol used to communicate with Cover Reports - <code>http</code> or <code>https</code> <strong>**</strong></td><td><code>http</code></td></tr></tbody></table>

> **\*** Disabling the Diffblue endpoint for telemetry data is only available to Diffblue Cover Enterprise Edition customers.
>
> **\*\*** See your Cover Reports Administrator for help, if needed.

{% hint style="info" %}
If IntelliJ is open when making any telemetry configuration updates, you'll need to restart IntelliJ to apply the changes.
{% endhint %}

**Example `telemetry.properties` file:**

```
# Copyright 2021-2024 Diffblue Limited. All Rights Reserved.
# Example telemetry.properties file
telemetry.external.enabled=true
telemetry.reports.enabled=true
telemetry.reports.hostname=localhost
telemetry.reports.port=8080
telemetry.reports.scheme=http
```

## Manage configurations

If you need to manage telemetry configuration across your organization, you can set the environment variables defined above (as needed) and apply these settings across your organization (for example, using a group policy).

{% hint style="info" %}
From release 2024.01.02, it is no longer possible to repackage Cover Plugin with telemetry disabled.
{% endhint %}


# Memory management

Tips for memory management, including how to increase the amount of memory that Diffblue Cover has access to.

## Minimum memory

The amount of memory utilized by Diffblue Cover depends on the complexity of the project being analysed - complex projects will require more memory than simple projects. The minimum system requirements are 16GB RAM with 8GB allocated as heap for Java to use. By default Java allocates a quarter of the total RAM as heap, therefore this must be overridden where the amount of RAM is less than 32GB. Recommended system requirements for running Diffblue Cover alongside other memory-intensive applications include 32GB of RAM.

## Out of memory due to complex projects

Not allocating enough heap to Java can result in out of memory errors - in these circumstances it is necessary to increase the memory available to Diffblue Cover above 8GB. As a rule of thumb, the memory requirements of Diffblue Cover are proportional to the memory requirements of the project being analysed.

## Cover Plugin - increasing memory

Cover Plugin for IntelliJ requires access to a minimum of 4GB of memory to run effectively. If you do not have enough memory available, Diffblue Cover will automatically adjust the memory setting. You can undo this change (but please note that your IDE may be unstable without sufficient memory).

If you wish to adjust the available memory manually, please go to **Help** > **Change Memory Settings** in IntelliJ and amend the **Maximum Heap Size** to at least 4096.

This will update the memory allocation in your `.vmoptions` file. Please restart your IDE for these changes to take effect.

## Cover CLI - increasing Java heap

The Java option `-Xmx<max heap size>` sets the maximum heap allocated to Java (more information about this option is available in the Java documentation; e.g. for Java 8 <https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html>.

Diffblue Cover utilizes the environment variable [`JVM_ARGS`](/features/cover-cli/project-configuration/runtime-environment) to specify Java options to use when running Diffblue Cover. Adding the Java option `-Xmx<max heap size>` to the `JVM_ARGS` environment variable will ensure that Diffblue Cover is allocated a specific portion of system memory.

{% tabs %}
{% tab title="Windows" %}
CMD example to set maximum heap available to Diffblue Cover to 8GB:

```groovy
set JVM_ARGS=-Xmx8g
```

PowerShell example to set maximum heap available to Diffblue Cover to 8GB:

```groovy
setx JVM_ARGS "-Xmx8g"
```

{% endtab %}

{% tab title="Linux/macOS" %}
Bash example to set maximum heap available to Diffblue Cover to 8GB:

```groovy
export JVM_ARGS=-Xmx8g
```

{% endtab %}
{% endtabs %}


# Using SonarQube with Cover Plugin

Tips for successfully using SonarQube with Cover Plugin for IntelliJ.

Tests written by Diffblue Cover may be reported as "code smells" by SonarQube. To suppress these warnings and reduce the reported "code smells" in the SonarQube output, go to `Diffblue > Change Settings > Method Annotations` and update the `Warnings to suppress` list, as needed - this will add the `@SuppressWarnings` code annotation to all test methods written by Diffblue Cover, as detailed below.

<div align="left"><figure><img src="/files/koFVNegdSQkP3YkLFe6m" alt=""><figcaption></figcaption></figure></div>

**Example - all:** `all`

Suppresses all warnings - adds the code annotation `@SuppressWarnings({"all"})`\`

**Example - types:** `unused,raw-types`

Suppresses one or more "warning types" - this example adds the code annotation `@SuppressWarnings({"unused","raw-types"})`

**Example - specific:** `squid:S2699`

Suppresses one or more specific warnings (using warning codes) - this example, adds the code annotation `@SuppressWarnings({"squid:S2699"}`

If you want to configure SonarQube directly, please see [Using SonarQube with Cover CLI](/features/cover-cli/cover-cli-admin/using-sonarqube-with-cover-cli)[.](https://github.com/diffblue/website-docs/blob/main/knowledge-base/cli/using-sonarqube-with-diffblue-cover/README.md)


# Log files

How to access the Diffblue Cover Plugin for IntelliJ log files, to better understand the tool's behavior and for debugging purposes.

## User logs

Cover Plugin creates and maintains a user log file, `user.log`, in the following locations:

**Windows:** `%USERPROFILE%\AppData\Local\Temp\diffblue\log`

**Linux:** `/tmp/diffblue/log`

**macOS:** `$TMPDIR/diffblue/log`

## Support logs

Cover Plugin also creates a `support.log` log file, in the same directory, which is only relevant to the Diffblue support team. If you raise a support issue then you may be asked to provide this log file.

## Accessing logs

Cover Plugin provides simple access to logs via the [Diffblue Cover tool window](/features/cover-plugin/writing-tests/diffblue-cover-tool-window#open-logs). After writing tests, simply look for the Open Logs button and select your desired action.

<div align="left"><figure><img src="/files/UtQ87Phd4eX50t0UpHLv" alt=""><figcaption></figcaption></figure></div>

* **Open user log:** Opens the diffblue user log - for this specific run - within IntelliJ IDEA.
* **Open support log:** Opens the diffblue support log - for this specific run - within IntelliJ IDEA.
* **Open logs folder:** Opens the folder containing all diffblue logs within Windows Explorer, Finder or equivalent.


# Troubleshooting

Hints and tips for troubleshooting Cover Plugin for IntelliJ.

This topic provides general troubleshooting information - please refer to the [Output Codes](/features/output-codes) topic for more specific details.

## Structural issues with the project

Please ensure that you are using Cover Plugin for IntelliJ on a complete project, as the plugin is unable to run successfully if there are flaws in the project structure. Check that:

* All modules in the project are configured correctly.
* The project is compilable.
* The Java SDK version is correct for your project.

***

## Test directories

IntelliJ looks for an existing test source directory. If an existing test source directory cannot be found, it will create one and then notify the user where the tests have been created.

***

## Memory settings

Diffblue Cover Plugin for IntelliJ requires 4GB of memory to run effectively. If you do not have enough memory available, Diffblue Cover will automatically adjust the memory setting. You can undo this change (but please note that your IDE may be unstable without sufficient memory).

If you wish to adjust the available memory manually, please go to **Help** > **Change Memory Settings** in IntelliJ and amend the **Maximum Heap Size** to at least 4096.

This will update the memory allocation in your `.vmoptions` file. Please restart your IDE for these changes to take effect.

***

## Error scenarios - inaccessible methods

If you are receiving spurious warnings about inaccessible methods, close IntelliJ and delete the `.diffblue index` file. A new one is automatically created when Cover Plugin is run again.

***

## Error scenarios - inotify watchers

In Linux, Diffblue Cover uses the inotify(7) filesystem API to watch for changes to your class files. If you are receiving an error message about running out of `inotify watchers`, please follow the advice below to increase the number of watch handles:

1. Add the following line to either the file `/etc/sysctl.conf` or a new `*.conf` file under the `/etc/sysctl.d/` directory: `fs.inotify.max_user_watches = 524288`
2. Then run this command to apply the change: `sudo sysctl -p --system`
3. Finally, restart your IDE. You should now have enough watch handles for IntelliJ to successfully create your tests.

***

## Resolving Formatting Conflicts between IntelliJ and Spotless

**Issue**:

Users may encounter formatting discrepancies when using Cover Plugin alongside other tools like Spotless. This can lead to unexpected changes in code formatting which may disrupt the development workflow.

**Cause**:

This issue typically arises when the formatting configurations in IntelliJ are not aligned with those specified by Spotless.

**Solution**:

To ensure consistent formatting and avoid any unexpected changes, we recommend that you align the formatting settings in IntelliJ with those of Spotless.

***

#### E166 - Ensure VM is correctly set up

If not already using google-java-format please check and upgrade your VM options in IntelliJ following the guidance here. [Ensure formatter compatibility](/features/cover-plugin/cover-plugin-admin/ensure-formatter-compatibility)


# Cover CLI

Diffblue Cover CLI automatically writes Java unit tests for your methods, classes, modules, and projects and provides access to the wider and deeper Diffblue Cover feature set. This set of topics provides all the details you need - for getting started information (installation, licensing, and test examples), see [Get started - Cover CLI](/get-started/get-started/get-started-cover-cli).

<table data-card-size="large" data-view="cards"><thead><tr><th data-type="files"></th><th></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td></td><td><p><mark style="color:blue;"><strong>Write Tests</strong></mark></p><p>Automatically write unit tests for your projects.</p></td><td></td><td><a href="/pages/jJZ7S2eFGuIm8lUnxxHl">/pages/jJZ7S2eFGuIm8lUnxxHl</a></td></tr><tr><td></td><td><p><mark style="color:blue;"><strong>Configure Your Projects</strong></mark></p><p>Set up your projects to get the best tests from Diffblue Cover.</p></td><td></td><td><a href="/pages/QvkFNVEoZtRq5c7MJCxJ">/pages/QvkFNVEoZtRq5c7MJCxJ</a></td></tr><tr><td></td><td><p><mark style="color:blue;"><strong>Commands &#x26; Arguments</strong></mark></p><p>Every command, every argument, every options - all the details you need.</p></td><td></td><td><a href="/pages/ZyGf7PJtCwoAYAMjWuOL">/pages/ZyGf7PJtCwoAYAMjWuOL</a></td></tr><tr><td></td><td><p><mark style="color:blue;"><strong>Admin</strong></mark></p><p>Get your admin done, including telemetry config, log files, memory management, etc.</p></td><td></td><td><a href="/pages/nRqLi36GlOjI6xBYdh3d">/pages/nRqLi36GlOjI6xBYdh3d</a></td></tr></tbody></table>

## eLearning

Basics first - just in case you missed the getting started video.

{% embed url="<https://youtu.be/eZkDQsYM9fA>" %}

Beyond the basics - try out the overview video.

{% embed url="<https://youtu.be/LPHw0JNcMyw>" %}


# Writing tests

How to automatically write Java unit tests using Cover CLI

To write tests using Cover CLI:

* To write tests for your entire project, open Windows PowerShell (Windows) or Terminal (macOS/Linux), navigate to your project, and enter the command `dcover create`
* To restrict tests to an individual package, class, or method, specify one or more entry points on the command line using `dcover create [<entryPoint>...]` - for example, `dcover create io.diffblue.corebanking.account.Account.`
* For a quick summary of core Cover CLI commands, see [Command summary](/features/cover-cli/writing-tests/command-summary) . For full details - every command, every argument, every option - see [Commands & Arguments](/features/cover-cli/commands-and-arguments).
* In general, `dcover create` will write complete tests for your methods, classes, modules, and projects. However, Cover is not always able to create a complete test, instead it may only be able to create partial tests - see [Creating partial tests](/features/cover-cli/writing-tests/partial-tests).
* Once Diffblue Cover starts to run, you can cancel the operation at any point by pressing **`CTRL-C`**.


# Command summary

## Command summary

<table><thead><tr><th width="196.49071125607543">Command</th><th>Description</th></tr></thead><tbody><tr><td><code>dcover create</code></td><td><strong>Create Tests</strong> - write tests for a project, package, method or class. See <a data-mention href="#create-tests">#create-tests</a>.</td></tr><tr><td><code>dcover create</code><br><code>--preflight</code></td><td><strong>Run Preflight Checks</strong> - verifies whether the local environment and the project are in the best condition possible for <code>dcover</code> to create tests, without actually creating the tests. See <a data-mention href="/pages/QvkFNVEoZtRq5c7MJCxJ">/pages/QvkFNVEoZtRq5c7MJCxJ</a> for full details.</td></tr><tr><td><code>dcover help create</code></td><td><strong>Help</strong> - display inline help for the dcover create command (syntax, available arguments, and short descriptions).</td></tr><tr><td><code>dcover version</code></td><td><strong>Check Version</strong> - display your Cover CLI version.</td></tr></tbody></table>

## Create tests

**Usage:** `dcover create [@<argumentFile>...] [<entryPoint>...] [--<argument>...]`

**Example:** `dcover create @argfile.txt io.corebanking.Account --maven`

**Inline help:** `dcover help create`

**Description:** The `dcover create` command writes tests for your projects, packages, classes, and methods.

* By default, `dcover create` automatically writes tests for the entire project. If required, you can specify what packages, classes, or methods you want to write tests for, on the command line (using `[<entryPoint>...]`) - see [Packages, classes, and methods](/features/cover-cli/commands-and-arguments/packages-classes-and-methods).
* You can use one or more optional arguments on the command line to specify additional Diffblue Cover options such as running preflight checks, excluding methods, or uploading reports bundles (using `[--<argument>...]`) - see the [Commands & Arguments](/features/cover-cli/commands-and-arguments#optional-arguments-dcover-create) topic.
* Command lines can become very long when multiple options are specified. To keep your command lines short and avoid any potential issues with terminals that don't support very long command lines, you can make use of argument files to define your optional arguments (using `[@<argumentFile>...]`) - see [Argument files](/features/cover-cli/commands-and-arguments/argument-files) for details.

## Output Codes

Cover CLI performs a number of checks before, during, and after creating unit tests. Cover can generate a range of output codes during these checks to provide general information and highlight any issues. Details for all output codes are provided in the main [Output Codes](/features/output-codes) topic. Note that as and when these output codes are displayed within Cover CLI, additional specifics may also be provided, if relevant. Also, some common issues can be resolved automatically using `dcover refactor` - see [Cover Refactor](/features/cover-refactor).


# Test examples

In this topic we show both the input source code, and the tests written by Diffblue Cover, for code of varied complexity, accompanied by a detailed narrative to help you further understand tests created by Diffblue Cover.

***

## Basic assertions <a href="#id-1-basic-assertions" id="id-1-basic-assertions"></a>

This is a simple example of Spring Service source code with a trivial getter. Cover can write a Spring Boot test for the getter in a service provider by inlining `Arrange`, `Act`, and `Assert`.

**Source**

```java
import org.springframework.stereotype.Service;

@Service
public class SimpleService
{
  public String getValue() {
    return "a really simple service";
  }
}
```

#### Test written by Diffblue Cover <a href="#id-12-test-generated-by-diffblue-cover" id="id-12-test-generated-by-diffblue-cover"></a>

```java
@SpringBootTest
@RunWith(org.springframework.test.context.junit4.SpringRunner.class)
public class SimpleServiceDiffblueTest {
  @Autowired
  private SimpleService simpleService;
  @Test
  public void diffbluetestGetValue() {
    // Arrange, Act and Assert
    assertEquals("a really simple service", this.simpleService.getValue());
  }
}
```

***

## Mocking <a href="#id-2-mocking" id="id-2-mocking"></a>

This is a class that contains two methods to upload and download a file to/from an Amazon S3 bucket. As the Amazon S3 bucket is a cloud storage mechanism, the test for this class/methods requires dependency injection. Cover can mock these types of dependencies and tests the `downloadFileFromBucket` method by asserting the expected `S3Object` and the downloaded `S3Object` using the method.

#### Source <a href="#id-21-source" id="id-21-source"></a>

```java
@Service
public class AmazonService {

  @Autowired
  private AmazonS3 s3client;

  public PutObjectResult uploadFileToBucket(String bucketName, String key, File file) {
    return s3client.putObject(bucketName, key, file);
  }

  public S3Object downloadFileFromBucket(String bucketName, String key) {
    return s3client.getObject(bucketName, key);
  }
}
```

#### Tests written by Diffblue Cover <a href="#id-22-tests-generated-by-diffblue-cover" id="id-22-tests-generated-by-diffblue-cover"></a>

```java
@SpringBootTest
public class AmazonServiceDiffblueTest {
  @MockBean
  private AmazonS3Client amazonS3Client;
  @Autowired
  private AmazonService amazonService;
  @Test
  public void diffbluetestUploadFileToBucket() {
    // Arrange
    PutObjectResult putObjectResult = new PutObjectResult();
    putObjectResult.setContentMd5("file-hash");
    when(this.amazonS3Client.putObject(or(isA(String.class), isNull()), or(isA(String.class), isNull()),
        or(isA(File.class), isNull()))).thenReturn(putObjectResult);

    // Act and Assert
    assertSame(putObjectResult, this.amazonService.uploadFileToBucket("foo", "foo",
        Paths.get(System.getProperty("java.io.tmpdir"), "test.txt").toFile()));
  }
  @Test
  public void diffbluetestDownloadFileFromBucket() throws UnsupportedEncodingException {
    // Arrange
    StringInputStream objectContent = new StringInputStream("file-name");
    S3Object s3Object = new S3Object();
    s3Object.setObjectContent(objectContent);
    when(this.amazonS3Client.getObject(or(isA(String.class), isNull()), or(isA(String.class), isNull())))
        .thenReturn(s3Object);

    // Act and Assert
    assertSame(s3Object, this.amazonService.downloadFileFromBucket("foo", "foo"));
  }
}
```

***

## OS agnostic assertions <a href="#id-3-os-agnostic-assertions" id="id-3-os-agnostic-assertions"></a>

This example returns time in a different format. Cover writes a test to assert date and time that is not dependent on operating system or local time zones.

#### Source <a href="#id-31-source" id="id-31-source"></a>

```java
public class TimeInAliceWonderland {

  private static final String DODO_DATETIME_FORMAT = "ss:mm:HH dd-MMM-yyyy";

  public static String reformatDodoDateTime(Date humanDate) {
    Map<String, DateFormat> dateFormatMap = new HashMap<>();
    dateFormatMap.put(DODO_DATETIME_FORMAT, new SimpleDateFormat(DODO_DATETIME_FORMAT));
    return dateFormatMap.get(DODO_DATETIME_FORMAT).format(humanDate);
  }
}
```

#### Test written by Diffblue Cover <a href="#id-32-test-generated-by-diffblue-cover" id="id-32-test-generated-by-diffblue-cover"></a>

```java
@Test
  public void diffbluetestReformatDodoDateTime() {
    LocalDateTime atStartOfDayResult = LocalDate.of(1970, 1, 1).atStartOfDay();
    assertEquals("00:00:00 01-Jan-1970", TimeInAliceWonderland
        .reformatDodoDateTime(
            Date.from(atStartOfDayResult.atZone(ZoneId.systemDefault()).toInstant())));
  }
```

***

## Example containing logic <a href="#id-4-example-containing-logic" id="id-4-example-containing-logic"></a>

In this example, Cover writes two tests to cover each pathway through the conditional - a test which adds 10 to the balance and asserts the new balance should be 20 and a second test where the account is closed.

#### Source <a href="#id-41-source" id="id-41-source"></a>

```java
public class Account {
  private final long accountNumber;
  private final Client client;
  private long currentBalance;
  private String accountName;
  private AccountState accountState;

  public Account(final long accountNumber, final Client client, final long amount) {
    this.accountNumber = accountNumber;
    this.client = client;
    currentBalance = amount;
    accountName = "Current";
    accountState = AccountState.OPEN;
  }

  public long getCurrentBalance() {
    return currentBalance;
  }

  public void addToBalance(final long amount) throws AccountException {
    if (getAccountState() != AccountState.OPEN) {
      throw new AccountException("Cannot add to balance, account is closed.");
    }
    currentBalance += amount;
  }
```

#### Test written by Diffblue Cover <a href="#id-42-test-generated-by-diffblue-cover" id="id-42-test-generated-by-diffblue-cover"></a>

```java
 @Test
  public void diffbluetestAddToBalance() throws AccountException {
    // Arrange
    Account account = new Account(1234567890L, new Client("Carlos Welch"), 10L);

    // Act
    account.addToBalance(10L);

    // Assert
    assertEquals(20L, account.getCurrentBalance());
  }
```

***

## Example of complex logic <a href="#id-5-example-of-complex-logic" id="id-5-example-of-complex-logic"></a>

This example code has three branches - Cover covers 100% of branches and creates three tests for three cases using existing enum values.

#### Source <a href="#id-51-source" id="id-51-source"></a>

```java
public class VirtualSnackCupboard {

  public static Snack whatCanISnackNow(int oClock) {
    if (oClock == 10) {
      return Snack.CHOCOLATE;
    } else if (oClock == 15) {
      return Snack.CAKES;
    } else {
      return Snack.VEGGIE;
    }
  }
  enum Snack {VEGGIE, CHOCOLATE, CAKES}
}
```

#### Tests written by Diffblue Cover <a href="#id-52-tests-generated-by-diffblue-cover" id="id-52-tests-generated-by-diffblue-cover"></a>

```java
  public void diffbluetestPickSnack() {
    assertEquals(VirtualSnackCupboard.Snack.CHOCOLATE, VirtualSnackCupboard.whatCanISnackNow(10));
    assertEquals(VirtualSnackCupboard.Snack.CAKES, VirtualSnackCupboard.whatCanISnackNow(15));
    assertEquals(VirtualSnackCupboard.Snack.VEGGIE, VirtualSnackCupboard.whatCanISnackNow(0));
  }
```

***

## Testing trivial methods

Diffblue Cover CLI deliberately does not test trivial methods such as getters, setters, constructors and factory methods to avoid creating large quantities of noisy tests that do not contribute to overall coverage. There isn't a benefit to be gained from testing these trivial methods directly as, for example, getters and setters simply access attributes so there is no actual logic to be tested. Similarly, constructors and factory methods also contain little or no logic. If Diffblue Cover CLI did test such methods directly, a minor coverage increase might be gained, but this "improvement" would be meaningless in terms of improving code quality.

Ultimately these trivial methods will be covered when Cover generates tests for other methods that call these trivial methods. Diffblue recommends improving the percentage of coverage using the many options within the product, as shown in the [Commands & Arguments](/features/cover-cli/commands-and-arguments) topic.


# Creating partial tests

By default, creation of partial tests is enabled in the Diffblue Cover Plugin for IntelliJ. This page covers partial tests and their uses, and how to turn off this option.

## About partial tests

Normally, `dcover create` will create *complete* tests for a method. A complete test consists of Arrange, Act, and Assert sections and passes when executed. However, sometimes Diffblue Cover is not (yet) able to write complete tests and will give the reason for not creating complete tests in the output summary. In these cases, you can opt to retrain the *partial* tests created by Cover using the `--keep-partial-tests` option. Partial tests may be incomplete in various aspects:

* The test does not have assertions.
* The test does not always pass when executed.
* The Arrange or Act sections produce an error when executed.
* The test may execute code that is potentially harmful to your system, leaks resources, or times out.

Creating partial tests is useful to developers for two reasons:

* Firstly, it will save developers time. Instead of writing tests from scratch, they'll be able to use the partial tests as a starting point.
* Secondly, it may help developers understand why Diffblue Cover was not able to *complete* the test automatically, especially in cases where the reason for not producing a test is lack of testability.

{% hint style="info" %}
Note that manually modified tests in test class files that are controlled by Diffblue (e.g. those suffixed with `DiffblueTest`) may be overwritten when running Cover the next time.
{% endhint %}

For example, for method `increment` in the following class:

```java
public class MyClass {
  private int x;
  public void increment() {
    ++x;
  }
}
```

Using `dcover create --keep-partial-tests`, Cover will create a *partial* test:

```java
  @Test
  public void testIncrement() {
    // TODO: This test is incomplete.
    //   Reason: R002 Missing observers.
    //   Diffblue Cover was unable to create an assertion.
    //   Add getters for the following fields or make them package-private:
    //     MyClass.x

    // Arrange
    MyClass m = new MyClass();

    // Act
    m.increment();
  }
```

The problem is clearly that Diffblue Cover has no opportunity to assert on the side effect of the `increment` method on field `x`, which is marked `private`. The developer could add a getter to `MyClass`:

```java
public class MyClass {
  private int x;
  public void increment() {
    ++x;
  }
  public int getX() {
    return x;
  }
}
```

Running `dcover create` again (with or without `--keep-partial-tests`) would now create a complete test.


# Customizing test inputs

How to customize test inputs

By default, Diffblue Cover will automatically choose input values to use when writing tests, but it's possible to provide custom inputs that may unlock additional coverage.

## Background

A key feature of Diffblue Cover is automatically identifying appropriate inputs necessary to write tests for a given method under test.

However, sometimes Diffblue Cover is unable to find appropriate inputs and thus does not produce useful tests. One such example is with the open source XXL-JOB project where Cover fails to produce tests for the `CronExpression` class, resulting in an [R013](/features/output-codes/r-reason-codes) output code:

```
com.xxl.job.admin.core.cron.CronExpression.<init>
  R013: No inputs found that don't throw a trivial exception
    Diffblue Cover tried to run the arrange/act section, but the method under
    test threw
    java.lang.NullPointerException
        at com.xxl.job.admin.core.cron.CronExpression.<init>(CronExpression.java:295)
    In order to prevent <init>(CronExpression)
    from throwing NullPointerException, add constructors or factory
    methods that make it easier to construct fully initialized objects used in
    <init>(CronExpression).
    See https://diff.blue/R013 to resolve this issue.
```

Also, because the `R013` occurs in the primary constructor for the class under test, Diffblue Cover is then unable to produce `CronExpression` instances for a further 28 methods and [R008](/features/output-codes/r-reason-codes) output codes:

```
com.xxl.job.admin.core.cron.CronExpression.addToSet
  R008: Failed to instantiate class under test
    Diffblue Cover was unable to construct an instance of CronExpression.
    Add a package-visible constructor or a factory method for testing which
    (ideally) takes no arguments, and does not throw, return null or return
    a subtype.
    See https://diff.blue/R008
```

These tests need input strings of a very specific format in order to successfully construct a `CronExpression` instance. In fact the javadoc in `CronExpression.java` devotes over 100 lines of comments to explaining the requirements for this format - helpfully providing an example of a valid cron expression string: `"0 0 14-6 ? * FRI-MON"`.

```yaml
java.lang.String:
  - immediate: "0 0 14-6 ? * FRI-MON"
    parameter: cronExpr
```

With this configuration file in place, when `java.lang.String` values are required, Diffblue Cover will try to use the constant cron expression value (`immediate: "0 0 14-6 ? * FRI-MON"`) if the parameter begins with `cronExpr` (`parameter: cronExpr`). Using just this one custom input allows this class to go from 54 tests with 21% line coverage to 194 tests with 59% line coverage.

## eLearning

{% embed url="<https://youtu.be/1xRWbErG92c?feature=shared>" %}

## Custom Inputs

You can specify custom inputs in a `DiffblueRules.yaml` or `DiffblueRules.yml` file. If both files exist in the same directory then both are read, with the `.yaml` variant taking precedence.

Diffblue Cover will stop with an [`E068`](/features/output-codes/e-environment-codes) error if the file is malformed due to wrong indentation or invalid rule syntax. This behavior is intended to give quick feedback so that the identified problem can be addressed, rather than waste time and resources attempting to create tests without all the custom rules.

If a rule is read successfully but the class can't be found, an [`E143`](/features/output-codes/e-environment-codes) warning will be given. This may be due to the class not being available (e.g. in a different module) or due to an incorrect class name. Test generation will not be stopped in this case.

### Custom Inputs for Strings

When writing unit tests, by default Diffblue uses **predefined / context**-**based** values for String objects. However, the user can come up with a specific String such as a name or a password. For example if the user needs to use “Peter” wherever in the codebase an argument called *clientName* appears and “rabbit” for an argument called *password*, the syntax will be:

```yaml
java.lang.String:
  - immediate: "Peter"
    parameter: clientName
  - immediate: "rabbit"
    parameter: password
```

This is shown in the image below:

<figure><img src="/files/wO2sBbT8uREnnMJ4UThg" alt=""><figcaption></figcaption></figure>

### Custom Inputs for Primitives

When writing unit tests, by default Diffblue uses **predefined / context**-**based** values for primitives such as `int`, `long`, etc. However, the user might want to push a certain value when tests are being written. For example, if the user wants a value of 11 for all primitives of type long to be used in the whole codebase, the following lines should be added in the `DiffblueRules.yaml`:

```yaml
long:
   - immediate: 11
```

If a particular primitive of long type such as `0987654321` is needed to match a certain method argument such as `accountNumber` in the whole codebase, the syntax should be:

```yaml
long:
 -  immediate : 987654321
    parameter: accountNumber
```

Finally, the user might decide to target a given method and one of its arguments. For example if the user wants the argument called `amount` in the method `addBalance()` to take the value 16, a syntax like this should be used:

```yaml
long:
  - immediate: 16
    parameter: amount
    method: addBalance
```

This is shown in the image below:

<figure><img src="/files/LkN1TXsxPuWYimd8YIuR" alt=""><figcaption></figcaption></figure>

### Custom Inputs for `.properties` files

Sometimes the user wants to use specific arguments such as URIs from a given file such as a `.properties` file.

For example:

`production-env.properties` contains `baseUri=https://app.example.com/`

and

`staging-env.properties` contains `baseUri=http://app.staging.example.com:8080/`

To have these URIs used in unit tests, there two options depending on the accessibility of the `.properties` files:

#### 1. Using files from the resources directory

In order to use `http://app.staging.example.com:8080/` from the `staging-env.properties` file in your unit tests, add the below lines to the `DiffblueRules.yaml` file. Note that for `resource` property files the path is taken from the module's test classpath location.

```yaml
java.util.Properties:
  - properties:
      resource: /staging-env.properties
```

#### 2. Using files at the root of the project

In order to use `http://app.staging.example.com:8080/` from the `staging-env.properties` file in your unit tests, add the below lines to the `DiffblueRules.yaml` file. Note that for `file` property files the path is taken from the root of the project.

```yaml
java.util.Properties:
  - properties:
      file: /staging-env.properties
```

## Rules Location

Custom rules are loaded from the project working directory and any of its ancestor directories. Assuming you have your project checked out into `~/Projects/MyProject` and are working with a module `SomeModule` within that, then rules will be read from each of the following locations in order, if they exist:

* `~/Projects/MyProject/SomeModule/DiffblueRules.yaml`
* `~/Projects/MyProject/SomeModule/DiffblueRules.yml`
* `~/Projects/MyProject/DiffblueRules.yaml`
* `~/Projects/DiffblueRules.yaml`
* `~/DiffblueRules.yaml`
* …
* `/DiffblueRules.yaml`

The intention here is that module and project level rules can be checked into the project source control system, but additional fallbacks into the user home directory are also possible. Rules are loaded from each discovered file in order, and so applicable rules local to the module will take precedence over rules defined at a wider scope.

## Rules Format

Custom rules are defined in a YAML format with the structure shown here. Rules are grouped by the type of input produced, and so the top level keys are the type being produced, each with a list of rules at the next level down. For example the following would mean that the constant values `"Diffblue"`, `"Cover"`, `"Custom"`, `"Inputs"` are all considered as candidate values to use whenever a `String` is required. Note that this does not guarantee that all of these constant values will be used, in practice the first candidate constant value may produce full coverage and so further candidate values are not needed.

```yaml
java.lang.String:
  - immediate: "Diffblue"
  - immediate: "Cover"
  - immediate: "Custom"
  - immediate: "Inputs"
```

### `immediate:` Rule

The first supported mechanism for producing values is via immediate constant values. This mechanism supports primitives, `java.lang.String`, and single- or multi-dimensional arrays of those types. Rules using this mechanism will have an `immediate: <constant>` component. Arrays of immediate values can be specified by adding one or more `[]` at the end of the normal type declaration, then using one of the YAML syntaxes for a list of values. For example, the following configuration specifies a single unconditional default rule for each supported type:

```yaml
boolean:
  - immediate: true

byte:
  - immediate: 65 # 0x41

char:
  - immediate: '*'

float:
  - immediate: 888.888f

double:
  - immediate: 12345.6789

int:
  - immediate: 7 # low values are recommended in case used for resource allocation

long:
  - immediate: -23

short:
  - immediate: 291 # 0x0123

java.lang.String:
  - immediate: "Lorem ipsum dolor sit amet"

java.lang.String[]:
  - immediate: [ "Hello", "World!" ]
  - immediate: # this rule uses different syntax for the same rule as above
    - "Hello"
    - "World!"

java.lang.String[][]:
  - immediate: [ [ "Multidimension", "arrays" ], [ "are", "also", "supported" ] ]
  - immediate: # this rule uses different syntax for the same rule as above
    - [ "Multidimension", "arrays" ]
    - [ "are", "also", "supported" ]
  - immediate: # this rule uses another syntax variation for the same rule
    - - "Multidimension"
      - "arrays"
    - - "are"
      - "also"
      - "supported"
```

### `factory:` Rule

The second supported mechanism for producing values is via factory methods. This mechanism supports producing class and interface instances and their single- or multi-dimensional arrays, but not enumerations, `java.lang.String` or primitives.

Factory methods must meet the following criteria in order to be used:

* Must be `static` methods or constructors.
* Must have `public` visibility.
* Any parameters must be able to take primitives, `java.lang.String`, `java.lang.Class`, or single- or multi-dimensional arrays of those types.
* Must have a return type assignable to the requested type.

Any factory methods that don't fit these criteria, or cannot be loaded with the user's classpath, will be silently ignored.

The factory rule syntax uses the `factory:` key with the following sub-keys:

* **`method:`** – Specifies the class and method name (e.g. `com.example.Foo.create`).\
  For constructors, use `<init>` (e.g. `com.example.Book.<init>`).
* (optional) **`params:`** – Lists the arguments passed to the method or constructor. If the method or constructor has parameters, they must be provided. If there are no parameters, this can be omitted.

```yaml
com.example.Book:
  - factory:
      method: com.example.Book.<init>
      params: [ "Title" ]
```

Cover will automatically determine the correct method or constructor based on the method name provided in the `method:` sub-key and values provided in the `params:`sub-key, selecting the most appropriate match. See [#handling-ambiguous-matches](#handling-ambiguous-matches "mention") if more specificity is needed.

For example, if you are working with a library then you might need to deal with International Standard Book Numbers in the form of an `ISBN` class, created by parsing ISBN formatted strings. Custom rules could be used to specify some valid `ISBN` values that can be used to test methods that require an `ISBN` instance:

```yaml
com.example.ISBN:
  - factory:
      method: com.example.ISBN.parse
      params: [ "1-56619-909-3" ] # An 'old' style ISBN-10 formatted identifier
  - factory:
      method: com.example.ISBN.parse
      params:
        - "978-1-56619-909-4" # A 'new' style ISBN-13 formatted identifier
  - factory:
      method: com.example.Platform.getBean
      params: [ com.example.ISBN ]
# For arrays 
com.example.ISBN[]:
  - factory:
      method: com.example.ISBNTestSupport.getIsbnArray
```

#### **Handling Ambiguous Matches**

Sometimes there are several constructors or factory methods for an object that accept the same number of parameters and compatible types. To specify exactly which method to use, you can provide a full method descriptor.

For example, a class may have multiple constructors:

```java
public Book() {}
public Book(String title) {}
```

```yaml
com.example.Book:
  - factory:
      method: com.example.Book.<init>
```

In this case, Cover cannot know whether you intended to use the no-argument constructor or the one with a single `String` parameter. It will proceed with one of the matches (typically the first match it finds with the fewest parameters).

To explicitly specify which constructor or method to use, you can provide a full `javap`-style descriptor, for example:

```yaml
com.example.Book:
  - factory:
      method: com.example.Book.<init>:()
```

or

```yaml
com.example.Book:
  - factory:
      method: com.example.Book.<init>:(Ljava/lang/String;)
```

The identifier must include a colon followed by a full `javap`-style method descriptor.

### `field:` Rule

The field rule can be used to produce values using constant fields. This mechanism supports object instances, `java.lang.String`, primitives and enumeration constants.

Fields must meet the following criteria in order to be used:

* Must have `public` visibility.
* Must be `static` .
* Must be `final` .
* Must have a type assignable to the requested type.

The field can be identified in the rule by using the fully qualified class name, followed by a dot, followed by the field name. For example, if you are working double values you could use the `java.lang.Math.PI` field as an input:

```yaml
double:
  - field: java.lang.Math.PI
```

You can also load enumeration constants. For example, given the following example:

```java
package com.example.myapp;

public enum MyEnum {
   ONE,
   TWO,
   THREE
}
```

You can specify specific enumeration constants to use as inputs using field rules:

```yaml
com.example.myapp.MyEnum:
  - field: com.example.myapp.MyEnum.ONE
  - field: com.example.myapp.MyEnum.TWO
```

### `properties:` Rule

The properties rule is a special case rule specifically for creating and populating a `java.util.Properties` instance.

The properties rule can specify a file using an absolute or relative path to a `.properties` file. When an absolute path is provided then that absolute path will be used directly from the test. When a relative path is provided then the properties file will be located relative to the `DiffblueRules.yaml`, and will be re-resolved against the project's working directory.

For example, given the following rule supplied in the project root:

```yaml
java.util.Properties:
  - properties:
      file: relative-file.properties
```

Then tests will attempt to populate a `java.util.Properties` instance as follows:

```java
BufferedReader newBufferedReaderResult =
  Files.newBufferedReader(Paths.get("relative-file.properties"));

Properties properties = new Properties();
properties.load(newBufferedReaderResult);
newBufferedReaderResult.close();
```

Alternatively the properties rule can specify a classpath resource to load. Resources are loaded relative to the class under test, so typically an absolute resource path should be used.

For example, given the following rule:

```yaml
java.util.Properties:
  - properties:
      resource: /resource.properties
```

Then tests of `ExampleApp` will attempt to populate a `java.util.Properties` instance as follows:

```java
InputStream resourceAsStream =
  ExampleApp.class.getResourceAsStream("/resource.properties");

Properties properties = new Properties();
properties.load(resourceAsStream);
resourceAsStream.close();
```

## Conditions

Typically a custom constant value is associated with one or more conditions for when this custom value should be used. When producing inputs for a particular method, supported conditions allow matching against the fully qualified class name, method name, or parameter name. For ease of use, matching is typically performed using case-insensitive substrings, but if finer control is required then the pattern can be wrapped in a `^` and `$` and the pattern will be treated as a regular expression instead.

Consider the following example code under test and the numbered contexts where string inputs need to be produced:

```java
package com.example.myapp;

public class StringProcessor {

  public static int parse(String text /* Context #1 */) {
    try {
      return Integer.parseInt(text);
    } catch (NumberFormatException e) {
      throw new IllegalArgumentException("Invalid input: " + text);
    }
  }

  public static String concatenateStrings(String str1 /* Context #2 */, String str2 /* Context #3 */) {
    return str1 + str2;
  }

  public static int getStringLength(String str1 /* Context #4 */) {
    return str1.length();
  }
}
```

```java
package com.example.myapp;

public class NumberProcessor {

    public static int processNumber(String str1 /* Context #5 */) {
        try {
            return Integer.parseInt(str1);
        } catch (NumberFormatException e) {
            throw new IllegalArgumentException("Invalid input: " + str1);
        }
    } 
}

```

### `class:` Condition

Class name conditions match against the fully qualified class name, `com.example.myapp.StringProcessor` in context #1-4 above, or `com.example.myapp.NumberProcessor` in context #5. For example `class: "example.myapp"` and `class: "^.*Processor$"` could both be used to match all contexts above.

### `method:` Condition

Method name conditions match against the name of the method, `parse` in context #1 above, `concatenateStrings` in #2-3. For example `method: "parse"` would match context #1, whereas `method: "^.*String.*$"` would match contexts #2-4.

### `parameter:` Condition

Parameter name conditions match against the name of the parameter, `text` in context #1 above, `str1` in contexts #2,4,5. For example `parameter: "text"` would match context #1 above, `parameter: "^str.*$"` would match contexts #2-5.

### Condition Combination

Up to one of each condition can be combined in a single rule, so for example the following rule can be used to offer the input "Hello World!" only in context #4 above:

```yaml
java.lang.String:
  - immediate: "Hello World!"
    method: "concatenateStrings"
    parameter: "str1"
```

When combining conditions with rules be careful about using the correct indentation, i.e., the condition should be indented to the same level as the rule itself. For example, when using a `factory:` rule with a `class:` condition the correct indentation is:

```yaml
java.io.File:
  - factory:
      method: java.io.File.<init>:(Ljava/lang/String;)V
      params: [ src/test/resources/testJPEG.jpg ]
    class: "com.example.SomeClass"
```

Note that the `class:` key is aligned with the `factory:` key, while `method:` and `params:` sub-keys of `factory:` are indented by 2 extra spaces.

### Full example

```yaml
java.lang.String:
  # Matches the first argument of the `concatenateStrings` method
  - immediate: "Hello "
    method: "concatenateStrings"
    parameter: "str1"
  # Matches the second argument of the `concatenateStrings` method
  - immediate: "World!"
    method: "concatenateStrings"
    parameter: "str2"
  # Matches arguments of methods whose name contains `String`
  - immediate: "Hello"
    method: "^.*String.*$"
  # Matches all arguments of methods in the `NumberProcessor` class
  - immediate: "800"
    class: com.example.myapp.NumberProcessor
  # Matches all arguments whose name starts with `str`
  - immediate: "Hello World!"
    parameter: "^str.*$"
```


# Customizing test setup

By default, Diffblue Cover will write tests that are executed in isolation but it's possible to provide a custom base class with additional logic to run before / after the tests themselves.

## Background

A key feature of Diffblue Cover is automatically configuring classes such that the method under test can be successfully executed.

However, sometimes Diffblue Cover is unable to appropriately configure and clean up the environment such that tests can be usefully written and needs guidance from the user in the form of a custom base class which can provide behavior inherited by the test class.

## eLearning

{% embed url="<https://youtu.be/TJnx2xPlL_4?feature=shared>" %}

## Custom Base Class

When writing tests for `com.example.SomeClass` Diffblue Cover will look for the existence of `com.example.SomeClassDiffblueBase` and use that as a super-class when writing `com.example.SomeClassDiffblueTest`. This `com.example.SomeClassDiffblueBase` class can contain methods to be run before/after writing tests, correctly annotated according to the testing framework used. The base class needs to have the same name as the class under test, with a `DiffblueBase` suffix appended, it must be in the same package as the class under test, but likely should be defined in the `src/test/java` source tree so that it’s kept separate from production code.

Note that if you're creating tests with TestNG for a class that uses Spring, the custom base class feature **cannot** be used.

Given a class under test: `src/main/java/com/example/SomeClass.java`

```java
package com.example;

class SomeClass {
  void methodUnderTest() {
    // ...
  }
}
```

and a custom base class: `src/test/java/com/example/SomeClassDiffblueBase.java`

```java
package com.example;

class SomeClassDiffblueBase {

}
```

then Cover will write a test class `src/test/java/com/example/SomeClassDiffblueTest.java` extending that custom base class.

{% tabs %}
{% tab title="JUNIT 4" %}

```java
package com.example;

import org.junit.Test;

class SomeClassDiffblueTest extends SomeClassDiffblueBase {
  @Test
  void testMethodUnderTest() {
    // Arrange
    // ...

    // Act
    // ...

    // Assert
    // ...
  }
}
```

{% endtab %}

{% tab title="JUNIT JUPITER 5" %}

```java
package com.example;

import org.junit.jupiter.api.Test;

class SomeClassDiffblueTest extends SomeClassDiffblueBase {
  @Test
  void testMethodUnderTest() {
    // Arrange
    // ...

    // Act
    // ...

    // Assert
    // ...
  }
}
```

{% endtab %}

{% tab title="TESTNG" %}

```java
package com.example;

import org.testng.annotations.Test;

class SomeClassDiffblueTest extends SomeClassDiffblueBase {
  @Test
  void testMethodUnderTest() {
    // Arrange
    // ...

    // Act
    // ...

    // Assert
    // ...
  }
}
```

{% endtab %}
{% endtabs %}

**Note:** Once the custom base class has been written or updated, please make sure that it has been compiled so that Cover is able to find the compiled class.

## `@BeforeXXX` Annotated Methods

The most common use case for using a custom base class is to customize the test setup, often to perform some static initialization of some environmental state.

For example, your base class might need to switch to some test environment before tests are run at all, and might need to reset some license limits ahead of each test run.

If your class under test needs some shared environment state to be set up before tests are run at all, you can add a static, visible, no-argument method to your base class annotated with `org.junit.jupiter.api.BeforeAll` (or `org.junit.BeforeClass` if using JUnit 4, respectively `org.testng.annotations.BeforeClass` if using TestNG) performing that initialization logic.

If your methods under test need some state setup or reset before each test is run, you can add a non-static, visible, no-argument method to your base class annotated with `org.junit.jupiter.api.BeforeEach` (or `org.junit.Before` if using JUnit 4, respectively `org.testng.annotations.BeforeMethod` if using TestNG) performing that initialization logic.

For example, your base class might look like the following, with `setupTestEnvironment()` being called once before `SomeClassDiffblueTest`, and `resetLicenseLimits()` being called before each test method found:

{% tabs %}
{% tab title="JUNIT 4" %}

```java
package com.example;

import org.junit.BeforeClass;
import org.junit.Before;

class SomeClassDiffblueBase {

  @BeforeClass
  public static void setupTestEnvironment() {
    // custom static configuration
    Environment.state = new TestEnvironment();
  }

  @Before
  public void resetLicenseLimits() {
    // reset license limits
    Licensing.remainingUsages = 100;
  }
}
```

{% endtab %}

{% tab title="JUNIT JUPITER 5" %}

```java
package com.example;

import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.BeforeEach;

class SomeClassDiffblueBase {

  @BeforeAll
  static void setupTestEnvironment() {
    // custom static configuration
    Environment.state = new TestEnvironment();
  }

  @BeforeEach
  void resetLicenseLimits() {
    // reset license limits
    Licensing.remainingUsages = 100;
  }
}
```

{% endtab %}

{% tab title="TESTNG" %}

```java
package com.example;

import org.testng.annotations.BeforeClass;
import org.testng.annotations.BeforeMethod;

class SomeClassDiffblueBase {

  @BeforeClass
  public void setupTestEnvironment() {
    // custom static configuration
    Environment.state = new TestEnvironment();
  }

  @BeforeMethod
  public void resetLicenseLimits() {
    // reset license limits
    Licensing.remainingUsages = 100;
  }
}
```

{% endtab %}
{% endtabs %}

## `@AfterXXX` Annotated Methods

A less common use case for a custom base class is to customize the test cleanup logic.

If your class under test needs some shared environment state to be cleared after tests are all run, you can add a static, visible, no-argument method to your base class annotated with `org.junit.jupiter.api.AfterAll` (or `org.junit.AfterClass` if using JUnit 4, respectively `org.testng.annotations.AfterClass` if using TestNG) performing that logic.

If your method under test needs some state reset after each test is run, you can add a non-static, visible, no-argument method to your base class annotated with `org.junit.jupiter.api.AfterEach` (or `org.junit.After` if using JUnit 4, respectively `org.testng.annotations.AfterMethod` if using TestNG) performing that logic.

For example, your base class might look like the following, with `resetLicenseUsageCount()` being called after each test in `SomeClassDiffblueTest` and then `resetTestEnvironment()` called after all the tests:

{% tabs %}
{% tab title="JUNIT 4" %}

```java
package com.example;

import org.junit.AfterClass;
import org.junit.After;

class SomeClassDiffblueBase {

  @AfterClass
  public static void resetTestEnvironment() {
    // clear test configuration
    Environment.state = null;
  }

  @After
  public void resetLicenseUsageCount() {
    // reset license limits
    Licensing.usageCount = 0;
  }
}
```

{% endtab %}

{% tab title="JUNIT JUPITER 5" %}

```java
package com.example;

import org.junit.jupiter.api.AfterAll;
import org.junit.jupiter.api.AfterEach;

class SomeClassDiffblueBase {

  @AfterAll
  static void resetTestEnvironment() {
    // clear test configuration
    Environment.state = null;
  }

  @AfterEach
  void resetLicenseUsageCount() {
    // reset license limits
    Licensing.usageCount = 0;
  }
}
```

{% endtab %}

{% tab title="TESTNG" %}

```java
package com.example;

import org.testng.annotations.AfterClass;
import org.testng.annotations.AfterMethod;

class SomeClassDiffblueBase {

  @AfterClass
  public void resetTestEnvironment() {
    // clear test configuration
    Environment.state = null;
  }

  @AfterMethod
  public void resetLicenseUsageCount() {
    // reset license limits
    Licensing.usageCount = 0;
  }
}
```

{% endtab %}
{% endtabs %}

## Field Inputs

Another use case for custom base classes is to provide initialized inputs that Cover would otherwise struggle to get right.

For example, perhaps your method under test requires some `ComplexObject` in order to execute, but it requires multiple calls to configure.

Note: Currently only static fields can be used.

Given a class under test: `src/main/java/com/example/SomeClass.java`

```java
package com.example;

class SomeClass {
  void methodUnderTest(ComplexObject complex) {
    // ...
  }
}
```

and a custom base class: `src/test/java/com/example/SomeClassDiffblueBase.java`

{% tabs %}
{% tab title="JUNIT 4" %}

```java
package com.example;

import org.junit.Before;

class SomeClassDiffblueBase {

  static ComplexObject complex;

  @Before
  public void resetTestEnvironment() {
    complex = ComplexObject.builder()
      .withName("For Unit Tests")
      .withSquareNumber(64)
      .build();
  }
}
```

{% endtab %}

{% tab title="JUNIT JUPITER 5" %}

```java
package com.example;

import org.junit.jupiter.api.BeforeEach;

class SomeClassDiffblueBase {

  static ComplexObject complex;

  @BeforeEach
  void resetTestEnvironment() {
    complex = ComplexObject.builder()
      .withName("For Unit Tests")
      .withSquareNumber(64)
      .build();
  }
}
```

{% endtab %}

{% tab title="TESTNG" %}

```java
package com.example;

import org.testng.annotations.BeforeMethod;

class SomeClassDiffblueBase {

  static ComplexObject complex;

  @BeforeMethod
  public void resetTestEnvironment() {
    complex = ComplexObject.builder()
      .withName("For Unit Tests")
      .withSquareNumber(64)
      .build();
  }
}
```

{% endtab %}
{% endtabs %}

Cover will use that initialized field to write the test class: `src/test/java/com/example/SomeClassDiffblueTest.java`

{% tabs %}
{% tab title="JUNIT" %}

```java
package com.example;

import org.junit.Test;

class SomeClassDiffblueTest extends SomeClassDiffblueBase {

  @Test
  public void testMethodUnderTest() {
    // Arrange
    SomeClass someClass = new SomeClass();

    // Act
    someClass.methodUnderTest(SomeClassDiffblueBase.complex);

    // Assert
    // ...
  }
}
```

{% endtab %}

{% tab title="JUNIT JUPITER 5" %}

```java
package com.example;

import org.junit.jupiter.api.Test;

class SomeClassDiffblueTest extends SomeClassDiffblueBase {

  @Test
  void testMethodUnderTest() {
    // Arrange
    SomeClass someClass = new SomeClass();

    // Act
    someClass.methodUnderTest(SomeClassDiffblueBase.complex);

    // Assert
    // ...
  }
}
```

{% endtab %}

{% tab title="TESTNG" %}

```java
package com.example;

import org.testng.annotations.Test;

class SomeClassDiffblueTest extends SomeClassDiffblueBase {

  @Test
  public void testMethodUnderTest() {
    // Arrange
    SomeClass someClass = new SomeClass();

    // Act
    someClass.methodUnderTest(SomeClassDiffblueBase.complex);

    // Assert
    // ...
  }
}
```

{% endtab %}
{% endtabs %}


# Test naming

Instructions on how to define the naming system used for tests generated by the Cover Plugin for IntelliJ.

By default, test classes created by Diffblue Cover are named `<CLASS_NAME>DiffblueTest` and test methods are named `test<INNER_CLASS_NAME><UNIT_NAME>`. To change the naming, use the class-name-template and method-name-template options as detailed below.

## Class name template

The `--class-name-template="${CLASS_NAME}<string>"` argument can be used to define the test class naming convention for tests written by Diffblue Cover. The `${CLASS_NAME}` variable will be substituted with the name of the class under test.

{% tabs %}
{% tab title="Windows" %}
**Usage:** `--class-name-template="${CLASS_NAME}<string>"`

**Example:** `--class-name-template="${CLASS_NAME}CreatedTest"`

**Default:** `${CLASS_NAME}DiffblueTest`
{% endtab %}

{% tab title="Linux/macOS" %}
**Usage:** `--class-name-template=\${CLASS_NAME}<string>`

**Example:** `--class-name-template=\${CLASS_NAME}CreatedTest`

**Default:** `${CLASS_NAME}DiffblueTest`
{% endtab %}
{% endtabs %}

{% hint style="info" %}
When using merge mode (`--merge`), the default class name template automatically changes to `${CLASS_NAME}Test` to enable merging into existing test classes. See [Merge Mode](/features/cover-cli/writing-tests/merge-mode) for details.
{% endhint %}

## Method name template

The `--method-name-template="<string><variable>[<variable>...]"` argument can be used to define the test method naming convention for tests written by Diffblue Cover. Available variables are as follows:

* The `${INNER_CLASS_NAME}` variable will be substituted with the name of the inner class for the method under test. If there's no inner class this will be an empty string.
* The `${UNIT_NAME}` variable will usually be substituted with the name of the method under test. Where the unit under test comprises multiple methods (getters and setters, equals and hash code) the more general unit under test name is used.
* The `${METHOD_NAME}` variable will be substituted with the name of the first method under test, typically the only method under test.
* The `${GIVEN}` variable will be substituted with a summary of the conditions prior to the method(s) under test being called, or a blank string if no description is available.
* The `${WHEN}` variable will be substituted with a summary of the conditions when the method(s) under test are called, or a blank string if no description is available.
* The `${THEN}` variable will be substituted with a summary of the consequences the method(s) under test being called, or a blank string if no description is available.
* The `${_}` variable will be substituted with a `_` separator, or a blank string if there are no values to separate.
* To avoid duplication, do not use `${UNIT_NAME}` and `${METHOD_NAME}` together.

{% tabs %}
{% tab title="Windows" %}
**Usage:** `--method-name-template="<string><variable>[<variable>...]"`

**Example:**\
`--method-name-template="aitest${INNER_CLASS_NAME}${METHOD_NAME}"`

**Default:** `test${INNER_CLASS_NAME}${UNIT_NAME}${_}${GIVEN}${_}${WHEN}${_}${THEN}`

For example, using the default naming convention for an inner class `Foo` with an `equals(Object)` and `hashCode()` implementation, a test method might be named `testFooEqualsAndHashCode_whenOtherIsEqual_thenReturnEqual`.
{% endtab %}

{% tab title="Linux/macOS" %}
**Usage:** `--method-name-template=<string><variable>[<variable>...]`

**Example:**\
`--method-name-template=testCreated\${INNER_CLASS_NAME}\${METHOD_NAME}`

**Default:** `test${INNER_CLASS_NAME}${UNIT_NAME}${_}${GIVEN}${_}${WHEN}${_}${THEN}`

For example, using the default naming convention for an inner class `Foo` with an `equals(Object)` and `hashCode()` implementation, a test method might be named `testFooEqualsAndHashCode_whenOtherIsEqual_thenReturnEqual`.
{% endtab %}
{% endtabs %}

## Disambiguation

Disambiguation between tests of the same name is performed automatically using sequential numbering:

```java
@Test
public class testAppendTitle {
    ...
}

@Test
public class testAppendTitle2 {
    ...
}
```


# Test formatting

The format of tests produced by Cover Plugin for IntelliJ can be configured via the "Test Formatting Options" within settings.

Use the `--output-comments=<value>` argument to select basic formatting options for tests written by Cover CLI (define the use of the `// Arrange`, `// Act`, and `// Assert` sections and comments).

**Usage:** `--output-comments=<value>`

**Example:** `--output-comments=false`

**Default:** `true`

### Brief

Using `--output-comments=false`, Cover CLI will create tests in a more condensed format - the `// Arrange`, `// Act`, and `// Assert` comments are removed and the sections are inlined:

```java
  @Test
  public void testHasItem() {
    assertFalse((new Order()).hasItem());
  }
```

### Standard

Using `--output-comments=true` (or not specifying the argument at all), the `Arrange`, `Act`, and `Assert` sections will be labelled, but may still be combined together by inlining if they're small, for example:

```java
@Test
public void testHasItem() throws Exception {
  // Arrange and Act
  boolean actual = (new Order()).hasItem();

  // Assert
  assertEquals(false, actual);
}
```


# Test insertion order

The order of insertion of test methods by Cover Plugin for Intellij

Created test methods are inserted into a test class in the same order that the methods under test appear in the source class (Diffblue Cover does not add a duplicate test if exactly the same test already exists).

### Source Class

```java
public class MyClass {
    public void xyz() {
    }
    public void abc() {
    }
}
```

### Test Class

```java
public class MyClassDiffblueTest {
    public void testXyz() {
    }
    public void testAbc() {
    }
}
```

As illustrated above, the test methods `testAbc` and `testXyz` are not inserted alphabetically into the test class, but instead according to how the methods under test are ordered. Test methods which test the same method are inserted in the order in which they are generated by Cover CLI.


# Patch files

How to create and use patch files for Cover CLI

Use the `--patch-only=<patch-file>` argument to define a patch file - Diffblue Cover will only write tests for the code changes defined in the patch file (any class in the patch and any related/dependent classes).

## Command line argument

**Usage:** `--patch-only=<patch-file>`

**Alternative:** `-p=<patch-file>`

**Example:** `--patch-only=path/to/file.patch`

* Use diff or a similar tool to create a patch file for your changes in your project - for example:\
  `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 - for example:

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

* The `--patch-only` argument 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
```

## Create a patch file

The exact patch file you need depends on your setup, but here are some examples using `git diff`. The variable `DIFFBLUE_PATCH` represents the name of your patch file.

***

For a patch containing commits newer than the project's origin (i.e. the corresponding branch on the remote repository your local branch was created from):

```groovy
git diff $(git rev-parse --abbrev-ref HEAD)...HEAD > $DIFFBLUE_PATCH
```

***

For a patch containing commits on your branch newer than those on the local copy of `TARGET_BRANCH` (e.g. where `TARGET_BRANCH` is `develop`):

```groovy
git diff TARGET_BRANCH...HEAD > $DIFFBLUE_PATCH
```

***

For a patch containing commits on your branch newer than those on the remote host `TARGET_BRANCH` (e.g. where `REMOTE` is `origin` and `REMOTE/TARGET_BRANCH` is `origin/develop`):

```groovy
git fetch REMOTE
git diff REMOTE/TARGET_BRANCH...HEAD > $DIFFBLUE_PATCH
```

***

For a patch containing only currently uncommitted changes:

```groovy
git diff > $DIFFBLUE_PATCH
```


# Diffblue Sandbox

\
Diffblue Cover writes unit tests by running your code thousands of times as it searches for the best tests that achieve maximum coverage and regression detection. By default, your code is run inside a sandbox which blocks calls with potentially disruptive side-effects such as network, file system, or system changes. However, this can also limit the number of tests that Diffblue Cover can write. Disabling the Diffblue sandbox will allow Cover to run all of your code regardless of side-effects, thereby maximizing coverage. Disabling the sandbox must be done with caution as your code may behave in ways you don't expect (e.g. file system modifications).

Note that if you receive the output code R011 when using Diffblue Cover, this means the method tested performs operations that violate Diffblue Cover’s sandbox policy.

## Sandbox Policy

| Sandbox Policy Enabled (Default)                                                                                                | <p>Sandbox Policy Disabled<br>(Changes Highlighted)</p>                                   |
| ------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Allow access to reflective Java operations (e.g. getting the list of methods of a class).                                       | Allow access to reflective Java operations (e.g. getting the list of methods of a class). |
| Allow setting properties (JUnit needs this during test execution).                                                              | Allow setting properties (JUnit needs this during test execution).                        |
| Allow creating classloaders.                                                                                                    | Allow creating classloaders.                                                              |
| Allow reads of all files.                                                                                                       | Allow reads of all files.                                                                 |
| Allow writes to files created in this session (including deletion).                                                             | **Allow writes of all files (including deletion).**                                       |
| Allow writes of files in `java.io.tmpdir` (including deletion).                                                                 | **Allow writes of all files (including deletion).**                                       |
| Deny writes of files, not created in this session and outside of `java.io.tmpdir` (including deletion).                         | **Allow writes of all files (including deletion).**                                       |
| Deny URL accesses (unless it's a `file://` url with a `GET` request, in which case it's treated like a regular file operation). | **Allow URL accesses.**                                                                   |
| Deny retrieving network information.                                                                                            | **Allow retrieving network information.**                                                 |
| Deny creating Sockets.                                                                                                          | **Allow creating Sockets.**                                                               |
| Deny GUI access.                                                                                                                | **Allow GUI access.**                                                                     |
| Deny `sun.misc.Unsafe`/`sun.misc.*`                                                                                             | **Allow `sun.misc.Unsafe`/`sun.misc.*`**                                                  |
| Deny external process accesses.                                                                                                 | **Allow external process accesses.**                                                      |
| Deny Java Management Extensions (JMX) access.                                                                                   | **Allow Java Management Extensions (JMX) access.**                                        |
| Deny Java Native Interface (JNI) access.                                                                                        | **Allow Java Native Interface (JNI) access.**                                             |
| Deny Smartcards (`java.smartcardio.*`).                                                                                         | **Allow Smartcards (`java.smartcardio.*`).**                                              |
| Deny Printers (`javax.print.*`).                                                                                                | **Allow Printers (`javax.print.*`).**                                                     |
| Deny setting the security manager.                                                                                              | **Allow setting the security manager.**                                                   |
| Deny access control context.                                                                                                    | **Allow access control context.**                                                         |
| Deny Kerberos Authentication access.                                                                                            | **Allow Kerberos Authentication access.**                                                 |
| Deny `System.exit` calls.                                                                                                       | Deny `System.exit` calls.                                                                 |

## Disabling the Diffblue Sandbox

The sandbox policy can be disabled to allow almost all of the operations outlined above (except calling `System.exit`). However, we recommend that you fully familiarize yourself with the information contained in this topic in order to avoid any undesirable effects by allowing these previously denied operations.

To disable the sandbox policy, use the `--disable-sandbox` option.

Note that if you just want to allow a small set of JNI libraries, use the JNI allow list (a comma separated list of JNI library name prefixes) - specified using the `--allow-jni=<value>[,<value>...]` argument.

Also, you may want to consider simply refactoring parts of your code. For example, if you have a method that executes a denied operation but also contains business logic that needs to be verified, you could refactor your code so that any logic that can be executed within the sandbox is contained in a separate, unit-testable method - this ensures the business logic is tested and consequently increases code coverage.

## Harmful Example

Let's look at an example of a denied operation and what *could* happen if it were allowed. One of the operations prevented by default is accessing files outside of the temp directory (specified by `java.io.tmpdir`). We further restrict this by allowing only *writing* to newly created files. The `root` parameter may end up pointing to a real directory on your system (it could be given any value, such as `/`, `C:\`, `/home/User/`), and then be executed, removing all the files contained within that directory along with the directory itself. With the *default* policy in place, trying to write tests for this method would result in an [R011](/features/output-codes/r-reason-codes) output code.

```java
public class Harmful {
    public void deleteRecursively(final Path root) {
        final File[] contents = directoryToBeDeleted.listFiles();
        if (contents != null) {
            for (final File file : contents) {
                deleteRecursively(file);
            }
        }
        return directoryToBeDeleted.delete();
    }
}
```

## Operations

The tables below outline the denied operations (Diffblue sandbox enabled) and explains what can happen (in the worst case) if they are allowed (Diffblue sandbox disabled). Note that:

* The exact nature of the risk is heavily dependent on the application being analyzed and can't be predicted ahead of time. If the application being analyzed is a web-based application in an automated pipeline that has no access to production systems, the risk of experiencing many of the adverse effects mentioned below is relatively low.
* The impact of the Diffblue sandbox policy is not restricted to just the method, but methods that call these methods, and so on.

### I/O Operation

<table data-full-width="true"><thead><tr><th width="156.4920634920635">Operation</th><th width="192">Allowed by Default?</th><th width="275">Change with "Disable Sandbox"</th><th>Possible Effect if Allowed</th></tr></thead><tbody><tr><td>Networking</td><td>No</td><td>Allowed</td><td>Unexpected network traffic, data loss on remote machines, instability in unit tests.</td></tr><tr><td>FileIO</td><td>Read all files, write new files.</td><td>Read all files, write all files.</td><td>Data loss on the machine where Cover is running, instability in unit tests.</td></tr><tr><td>TmpFileIO</td><td>Read all files, write new files.</td><td>Read all files, write all files.</td><td>Unnecessary disk space is consumed, instability in unit tests.</td></tr></tbody></table>

* Data loss is likely to occur if methods (like a hypothetical `delete` method in a typical web application) are invoked and happen to have access to live credentials (e.g. production or test environments).
* Likewise, unexpected network traffic can occur if the application makes raw network requests to servers.
* Disk space may be consumed because the application may not clean up temporary files.

### Java Libraries

<table data-full-width="true"><thead><tr><th width="203.5">Library</th><th width="240">Allowed by Default?</th><th width="275">Change with "Disable Sandbox"</th><th>Possible Effect if Allowed</th></tr></thead><tbody><tr><td>GUI (Swing/AWT)</td><td>No, <code>java.awt.headless</code> is set to <code>true</code></td><td>Allowed, <code>java.awt.headless</code> is set to <code>false</code></td><td>N/A</td></tr><tr><td><code>sun.misc.*</code></td><td>No</td><td>Allowed</td><td>Instability of tests across JVM vendors and operating systems.</td></tr><tr><td><code>sun.misc.Unsafe</code></td><td>No</td><td>Allowed</td><td>Unintended side effects across unit tests in a class, or test suite.</td></tr></tbody></table>

* Trying to write unit tests for methods that invoke GUIs is difficult. In those cases, the `java.awt.headless` property is usually set to `true` to disable those GUI components. If you require tests for the logic behind the GUIs, it's better to refactor the code to allow that logic to be tested independently of the GUI.
* The `sun.misc.*` packages provide very low level access to fundamental system operations and do not form a part of the public interface. Because of the very low level access, we deem these operations unsafe due to the risk of unintended side effects.
* Furthermore, the following is taken from the published Oracle [FAQ](https://www.oracle.com/java/technologies/faq-sun-packages.html) regarding the use of these packages.

> The `sun.*` packages are not part of the supported, public interface.
>
> A Java program that directly calls into `sun.*` packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform.
>
> Each company that implements the Java platform will do so in their own private way. The classes in `sun.*` are present in the JDK to support Oracle's implementation of the Java platform: the `sun.*` classes are what make the Java platform classes work "under the covers" for Oracle's JDK. These classes will not in general be present on another vendor's Java platform. If your Java program asks for a class `"sun.package.Foo"` by name, it may fail with `ClassNotFoundError`, and you will have lost a major advantage of developing in Java.
>
> Technically, nothing prevents your program from calling into `sun.*` by name. From one release to another, these classes may be removed, or they may be moved from one package to another, and it's fairly likely that their interface (method names and signatures) will change. (From Oracle's point of view, since we are committed to maintaining the Java platform, we need to be able to change `sun.*` to refine and enhance the platform.) In this case, even if you are willing to run only on Oracle's implementation, you run the risk of a new version of the implementation breaking your program.
>
> In general, writing java programs that rely on `sun.*` is risky: those classes are not portable, and are not supported.

### System Operations

<table data-full-width="true"><thead><tr><th width="180">Operation</th><th width="189.25">Allowed by Default?</th><th width="274">Change with "Disable Sandbox"</th><th>Possible Effect if Allowed</th></tr></thead><tbody><tr><td>External Processes</td><td>No</td><td>Allowed</td><td>Instability of unit tests, random behavior of other processes.</td></tr><tr><td>JMX</td><td>No</td><td>Allowed</td><td>Instability of unit tests, random behavior of JMX enabled beans/services/etc.</td></tr><tr><td>JNI</td><td>No, except JNI allow list - see below.</td><td>Allowed</td><td>Tests won't generate coverage for the native code.</td></tr><tr><td><code>System.exit</code></td><td>No</td><td>No</td><td>Causes the analysis service JVM to exit and would increase in the occurrence of R024/R025 output codes (from Diffblue Cover).</td></tr></tbody></table>

**\*** Note that if the Diffblue sandbox policy is blocking access to a JNI library that you believe to be safe to use, then you can add it to the JNI allow list (a comma separated list of JNI library name prefixes can be used):

* **Cover CLI:** Use the `--allow-jni` option - see [allow-jni](/features/cover-cli/commands-and-arguments#allow-jni) and/or [Working with code R012](/features/output-codes/working-with-output-codes/working-with-code-r012) for more information.
* **Cover Plugin:** Go to `Diffblue > Change Settings > Sandboxed Environment > Allowed JNI prefixes`.

### Peripherals

Generally, these operations require access to specific hardware which may or may not be present. Because this can't be determined beforehand, unit tests for methods using these APIs would be inherently unstable.

<table data-full-width="true"><thead><tr><th width="167.4">Peripheral</th><th width="183">Allowed by Default?</th><th width="271">Change with "Disable Sandbox"</th><th>Possible Effect if Allowed</th></tr></thead><tbody><tr><td>Smartcards</td><td>No</td><td>Allowed</td><td>Corruption of data on the smartcards.</td></tr><tr><td>Printing</td><td>No</td><td>Allowed</td><td>Print jobs are submitted to configured printers.</td></tr></tbody></table>

### Security

<table data-full-width="true"><thead><tr><th width="169">Security</th><th width="185">Allowed by Default?</th><th width="267">Change with "Disable Sandbox"</th><th>Possible Effect if Allowed</th></tr></thead><tbody><tr><td>Setting security manager</td><td>No</td><td>Allowed</td><td>Unit tests won't be created or verified.</td></tr><tr><td>Create access control context</td><td>No</td><td>Allowed</td><td>Attempts to bypass sandbox will be allowed.</td></tr><tr><td>Kerberos Authentication</td><td>No</td><td>Allowed</td><td>Unintended side-effects with Kerberos systems.</td></tr></tbody></table>


# Test Coverage Optimizations

Diffblue Cover can create many tests for a given package, class or even method, but how does Cover optimize the tests that it provides? And what options are there to help make sure that Diffblue Cover provides you the test coverage levels that you prefer?

***

### Test Class Coverage Optimization (Default)

By default, Diffblue Cover will optimize test output by only providing tests which increase coverage within the target test class.

#### What does Test Class Coverage Optimization look like?

* For a source class Foo
* Cover will create a test class called FooDiffblueTest
* Cover will start to create test methods that exercise the contents of Foo and insert them into FooDiffblueTest
* When a new test candidate is found by Cover, and its coverage does not increase upon the coverage in FooDiffblueTest, then it will be discarded.

Through this methodology, Cover will aim to provide the minimum number of test methods to deliver the maximum coverage, in the test class.

#### Merge Mode and Test Class Coverage Optimization

When using merge mode (`--merge` in CLI, or `${CLASS}Test` template in the plugin), Test Class Coverage Optimization becomes even more powerful. Because generated tests are merged into your existing `*Test.java` files alongside your manual tests, Diffblue Cover can consider your manual tests when determining which generated tests add unique coverage.

This means:

* Less duplication between generated and manual tests
* More focused test generation that complements your existing test suite
* Better overall coverage efficiency

See [Merge Mode](/features/cover-cli/writing-tests/merge-mode) for details on enabling merge mode.

#### What does Test Class Coverage Optimization not do?

* It does not consider coverage provided by test classes outside of the target test class.
* It does not guarantee that each test provides unique coverage, in fact it is highly likely that there will still be coverage overlap between test methods within the same test class, just as there would be with manual testing. However each test will provide some unique coverage, within the test class.

#### Disabling Test Class Coverage Optimization (ignore existing coverage)

Disabling test class coverage optimization will allow Diffblue Cover to provide the maximum number of tests, including tests which provide duplicated coverage. This may increase test strength and mutation coveage.

This can be achieved in the CLI and Plugin through use of the `--ignore-existing-coverage` options. See CLI: [Commands & Arguments](/features/cover-cli/commands-and-arguments) Plugin: [Cover Plugin settings](/features/cover-plugin/cover-plugin-settings)

{% hint style="info" %}
Currently Test class coverage optimisation only support the JUnit Jupiter platform. For JUnit 4 / TestNG environments test class coverage optimisation will not be applied.
{% endhint %}

***

### Test Suite Coverage Optimization (new jacoco coverage)

Optionally, Cover can optimize coverage across the entire test suite using the CLI option --new-jacoco-coverage. This will take into account the coverage provided by existing tests before starting to create Diffblue Tests. Tests created by Diffblue Cover are added if they increase JaCoCo coverage.

Notable effects:

* This has the ability to greatly reduce the number of DiffblueTests produced by Diffblue Cover, depending on existing test coverage levels.
* This feature will reduce the overlap between Diffblue and Manual test cases, however not all overlap will be eliminated, while maintaining the same overall Coverage levels.
* This feature may cause many Diffblue tests to be discarded that may be better quality than existing tests, or test other values or edge cases. This will likely reduce the overall strength and mutation coveage provided of the test suite.
* If used in conjunction with `--ignore-existing-coverage` then Diffblue Cover may still provide redundant coverage within its own test classes.

For more information see [Commands & Arguments](/features/cover-cli/commands-and-arguments)

{% hint style="warning" %}
The `--new-jacoco-coverage` option can be valuable for high quality, trusted, test suites, allowing Diffblue Cover to focus on adding new coverage to round out the test suite without adding code bloat.

**However,** if you are looking to modernise your test suite, code or are at all unsure of the veracity of your test suite, then we would encourage you to take advantage of Covers ability to generate high quality, high strength tests, at scale, by NOT using this option. Once you have your Cover augmented test suite, consider the coverage and test strength improvements Cover has provided and balance that against any coverage or test duplication, you may find that deleting flakey or poorly understood manual tests is the correct approach for you.
{% endhint %}


# Merge Mode

Merge mode enables Diffblue Cover to merge generated tests into existing test classes rather than creating separate files.

## Overview

Merge mode is an optional test generation approach where Diffblue Cover **merges generated tests into existing test classes** rather than creating separate test files. This provides a more natural integration with your existing test suite.

**Default Behavior (Separate Files):**

```
src/test/java/com/example/
├── MyServiceTest.java          (your manual tests)
└── MyServiceDiffblueTest.java  (Diffblue generated tests - separate file)
```

**With merge mode (`--merge` flag):**

```
src/test/java/com/example/
└── MyServiceTest.java          (your manual tests + generated tests merged together)
```

## Why Use Merge Mode?

Merge mode provides several benefits:

1. **Simpler Project Structure** - All tests for a class live in one file, with no separate `*DiffblueTest` files
2. **Easier Navigation** - Find and maintain tests in a single location alongside your manual tests
3. **Smarter Test Class Coverage Optimization** - Diffblue Cover considers your manual tests, then provides only the generated tests that add unique coverage. See [Test Coverage Optimizations](/features/cover-cli/writing-tests/test-coverage-optimizations) for details.

## Enabling Merge Mode

### CLI

To use merge mode with the CLI, add the `--merge` flag:

```bash
dcover create --merge
```

With `--merge`, the default class name template changes to `${CLASS_NAME}Test`. If your existing test classes use a different naming convention, you can override this with `--class-name-template`:

```bash
dcover create --merge --class-name-template='${CLASS_NAME}Tests'
```

See [Test naming](/features/cover-cli/writing-tests/test-naming) for all available template variables.

### IntelliJ Plugin

Merge mode is enabled by default in the IntelliJ plugin. However, the plugin uses `${CLASS_NAME}DiffblueTest` by default, which keeps generated tests in separate files.

To take advantage of merge mode, update the class name template in your plugin settings to match your existing test naming conventions (e.g., `${CLASS_NAME}Test`). This allows generated tests to merge into your existing test classes.

See [Test Naming](/features/cover-plugin/cover-plugin-settings/test-naming) for plugin settings details.

## Key Behavior Differences

| Aspect            | Default Behavior            | With `--merge`                  |
| ----------------- | --------------------------- | ------------------------------- |
| Test file naming  | `${CLASS_NAME}DiffblueTest` | `${CLASS_NAME}Test`             |
| Test placement    | Separate file               | Merged into existing test class |
| Existing tests    | Not touched                 | Preserved, new tests added      |
| Test updates      | File replaced               | Individual tests updated        |
| cover-annotations | Not required                | Required (v1.4.0+)              |

***

## Prerequisites

### cover-annotations Requirement

**When using `--merge`, the `cover-annotations` library version 1.4.0 or later is required.**

If the library is missing or outdated when using `--merge`, Diffblue Cover displays an error during environment checks and halts execution. This requirement does not apply when running without `--merge`.

{% tabs %}
{% tab title="Maven" %}
Add to your `pom.xml`:

```xml
<dependency>
    <groupId>com.diffblue.cover</groupId>
    <artifactId>cover-annotations</artifactId>
    <version>1.9.0</version>
    <scope>test</scope>
</dependency>
```

{% endtab %}

{% tab title="Gradle (Groovy)" %}
Add to your `build.gradle`:

```groovy
compileOnly 'com.diffblue.cover:cover-annotations:1.9.0'
testImplementation 'com.diffblue.cover:cover-annotations:1.9.0'
```

{% endtab %}

{% tab title="Gradle (Kotlin)" %}
Add to your `build.gradle.kts`:

```kotlin
compileOnly("com.diffblue.cover:cover-annotations:1.9.0")
testImplementation("com.diffblue.cover:cover-annotations:1.9.0")
```

{% endtab %}
{% endtabs %}

See [Cover Annotations](/features/cover-annotations) for more information about the annotations library.

***

## Troubleshooting

### R090: Failed to Merge Tests

When you see this error:

```
[R090] Failed to merge tests into test class

Failed to merge tests into test class for com.example.MyService.

To resolve this, you can:
- Add @WriteTestsTo("MyServiceDiffblueTest") annotation to MyService, or
- Run Diffblue Cover without the --merge flag

You can customize the annotation value to any valid Java class name.
```

**What R090 means:** Diffblue Cover attempted to merge generated tests into an existing test class, but the merge failed. This happens when:

* The existing test class has code that conflicts with the generated tests
* Tests fail validation after merging (compile errors, test failures)

#### Solution 1: Use dcover issues --prompt (Recommended)

Run `dcover issues --prompt` to get an AI-assistant-ready prompt that will help you apply the necessary annotations:

```bash
dcover issues --prompt
```

#### Solution 2: Use @WriteTestsTo Annotation

Add the `@WriteTestsTo` annotation to direct tests to a separate file:

```java
package com.example;

import com.diffblue.cover.annotations.WriteTestsTo;

@WriteTestsTo("MyServiceDiffblueTest")
public class MyService {
    // Tests will be written to MyServiceDiffblueTest.java
    // instead of merging into MyServiceTest.java
}
```

See [Test Organization Annotations](/features/cover-annotations/test-organization-annotations) for more details on `@WriteTestsTo`.

#### Solution 3: Remove --merge Flag

Run without `--merge` to use the default separate-file behavior:

```bash
dcover create
```

### Environment Check Failures

#### Missing or Outdated cover-annotations

**Error:** Diffblue Cover requires `cover-annotations` when using `--merge` and fails when the dependency is missing or below version 1.4.0.

**Solution:** Add or update the `cover-annotations` dependency (see Prerequisites section). Version 1.9.0 or later is recommended.

***

## Adopting Merge Mode

### From Existing \*DiffblueTest Files

If you have existing `*DiffblueTest` files and want to switch to merge mode:

1. **Remove existing Diffblue tests:**

   ```bash
   dcover remove
   ```
2. **Regenerate tests with merge mode:**

   ```bash
   dcover create --merge
   ```
3. **Review the merged tests** in your `*Test.java` files

### CI/CD Considerations

If you have CI/CD pipelines using Diffblue Cover and want to adopt merge mode:

1. Add `cover-annotations` 1.4.0+ to all build environments
2. Run `dcover remove` once to clean up existing `*DiffblueTest` files
3. Update `dcover create` commands to include `--merge` flag
4. Update any scripts that reference `*DiffblueTest` file patterns

***

## Known Limitations

### IntelliJ Plugin

* If merge fails in the plugin, you may receive tests with compilation errors that require manual resolution
* The plugin does not validate merged tests the same way the CLI does

### Cover Reports

Merge mode does not affect how Cover Reports attributes coverage. Diffblue Cover uses annotations (`@ManagedByDiffblue`, `@MethodsUnderTest`, `@Tag("ContributionFromDiffblue")`) to correctly identify generated tests regardless of file location.

***

## Related Topics

* [Test naming](/features/cover-cli/writing-tests/test-naming) - Class and method naming templates
* [Test Coverage Optimizations](/features/cover-cli/writing-tests/test-coverage-optimizations) - How merge mode enhances coverage optimization
* [Test Organization Annotations](/features/cover-annotations/test-organization-annotations) - @WriteTestsTo annotation details
* [Commands & Arguments](/features/cover-cli/commands-and-arguments) - Full CLI reference


# Operational behaviors

Diffblue Cover operates by making best-effort, automated decisions based on available data, in circumstances where multiple choices are available or where unsupported options are being used. This allows Cover to provide high quality tests without the need to pedantically “fix” every minor deviation from a perfect project. For example, if your project uses Java 4 **and** Java 5, Cover will automatically select Java 5 to ensure compatibility.

Operating in this manner, Cover provides warnings to highlight changes that you should consider and will only exit with errors if there’s a high chance of making an incorrect selection or if there’s an issue/option that can’t be resolved automatically.

Cover CLI also provides a `--strict` command line option which forces the strict definition of all project environment options set by you and the strict use of supported options only - Diffblue Cover will not attempt to make automated selections. When using `--strict`, you’ll need to resolve any issues that cause an error – for example, if your project uses Java 4 **and** Java 5, you will need to specify which Java version to use, on the command line.

Cover’s default behavior is useful during development to provide a little flexibility. Using `--strict` is only necessary when preparing for production to help ensure “quality compliance” - once all errors have been addressed you will have the optimal conditions for test creation and therefore get the optimal quantity and quality of tests.




---

[Next Page](/llms-full.txt/1)