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

1. Getting started using Cover: enable your developers to use Cover efficiently in their daily workflows (CI Pipeline, CLI, IntelliJ plugin).

2. Introduction to Cover Reports: enable engineering managers to use Cover Reports to assess the value received from 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

Discover the details

Product specific:

General information:

Detailed learning paths targeted at DevOps:

Achievements:

• Understand the use of Diffblue Cover within a CI/CD environment.

To write tests using Cover Plugin for IntelliJ:

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 .

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 .

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.

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 , Jumpstart proceeds in the following three phases.

1. : help your champions set up Cover on your first projects and enable your champions to roll out to more projects on their own.

2. : teach your developers how to use Cover efficiently and understand the value that you get from Cover.

Cover Plugin Settings

To reset Cover Plugin Settings:

1. Open the Cover Settings panel in the IntelliJ IDE.

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 .

Example - all: all

Suppresses all warnings - adds the code annotation @SuppressWarnings({"all"})`

Example - types: unused,raw-types

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 and decide which one is the best fit for you. We will then guide you towards the implementation of the chosen deployment.

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: 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: integrate Cover into the CI system of your first projects.

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.

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.

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

1. Speed up your test execution: slash test execution times with Cover Optimize in CI and locally.

2. Getting more from Cover: tips and tricks to write more tests with Cover and improve the testability of your codebase.

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.

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.

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

@ContextConfiguration(classes = {AmazonService.class})
@ExtendWith(SpringExtension.class)
class AmazonServiceDiffblueTest {
    @MockBean
    private AmazonS3 amazonS3;

    @

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.

Some basics

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

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.

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).

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.

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.

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.

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: This is the most basic deployment which does not make use of a CI/CD system and thus entails most manual effort.

2. : 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. : This deployment is suitable if your CI/CD system tends to be slow on pull requests.

4. : 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.

You need to on a central server and and on developer workstations. 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.

You need to on a central server and and on developer workstations. 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.

You need to on a central server, in your CI/CD system and and on developer workstations. 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.

You need to on a central server, in your CI/CD system and and on developer workstations. 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.

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 and .

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 .

For more details, including troubleshooting, see the main 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 topic.

Editions

Diffblue Cover is licensed according to the four which determine what features and limits apply to your use of Diffblue Cover. Please see for more details.

Diffblue license manager

According to the terms of your subscription, you may be given access to the 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.

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.

• 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.

Note: To update Cover Reports, see .

Detailed learning paths targeted at developers:

Achievements:

• Understand Diffblue Cover specifications and requirements and how to configure your projects for automated test writing.

• Know how to use Diffblue Cover to write tests for your projects - basic and advanced concepts.

• Understand output codes and how to resolve them.

• Know how to improve test coverage for your code base, including automated refactoring.

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.

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.

Improve, monitor, and manage your test coverage:

Achievements:

• Know how to improve, monitor, and manage your test coverage.

• Know how to improve test coverage for your code base, including automated refactoring.

• Understand output codes and how to resolve them.

• Understand how to use Cover Reports to monitor and manage test coverage.

• Know how to manage your Cover Reports instance including installation, database backups, and software updates.

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

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 with Diffblue Cover - download, install, license, and play:

Achievements:

• Learn what Diffblue Cover is and how it works.

• Know how to download, install, and license Diffblue Cover.

• Know how to use Diffblue Cover to write tests (basic concepts) and how to start applying this to your own code.

The Write Tests menu option can be used throughout IntelliJ:

• Right click in the Project Tool Window.

• Right click in the Structure Tool Window.

• Right click in the Text Editor.

• Use the .

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).

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.

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).

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.

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

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.

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.

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

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 . For full details - every command, every argument, every option - see .

• 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 .

• Once Diffblue Cover starts to run, you can cancel the operation at any point by pressing CTRL-C.

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

Use Cover Reports to monitor and manage test coverage.

About partial tests

Normally, selecting 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 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).

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

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

Test Class

This topic provides general troubleshooting information - please refer to the 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 Cover Plugin toolbar menu provides many actions for the user:

• Write tests & Write Skeleton tests. For more information see .

• Change Settings. For more information see .

• Clear Environment Check Cache. For more information see

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 .

eLearning

Basics first - just in case you missed the getting started video.

Beyond the basics - try out the overview video.

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

Test Class

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.

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

Achievements:

• Understand how to install, update, manage, and maintain Diffblue Cover, including config options and license management.

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.

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

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.

Start here...

Alternatives...

Next steps...

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

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

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.

eLearning

Just in case you missed our getting started video.

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 and Diffblue 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 or ) or . 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 or .

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 and .

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.

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.

Reviewing a test

To help you review your tests, we display them inside a . 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.

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.

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.

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 icon. Once all tests for the method have been reviewed, this icon will be replaced according to the status of the tests.

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.

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

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.

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.

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.

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 . 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 below).

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.

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.

Cancel tests

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

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.

Restart test generation

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

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 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 for more details).

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 or select Write Tests - Diffblue Cover will analyze the method and related classes to write one or more complete tests (or 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 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:

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 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:

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 .

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.

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: Plugin:

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

For more information see

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

Status icons

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.

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)

Create coverage reports and improve test coverage. This learning path is targeted at developers - see the Test Coverage group for all coverage related learning paths.

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.

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 .

Command summary

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 .

• 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 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

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 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 .

Common Cover Plugin admin:

• Telemetry Config: Enable/disable and configure telemetry for Cover Plugin.

• Memory Management: Tips for memory management, including how to increase the amount of memory that Diffblue Cover has access to.

• SonarQube: Suppress warnings and reduce reported "code smells" in SonarQube.

• : User and Support Log Files.

• : Help with a few common issues that you may encounter.

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.

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.

Disambiguation

Disambiguation between tests of the same name is performed automatically using sequential numbering:

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

Start here...

Alternatives...

Licensing Diffblue Cover in the offline mode detailed here is available only when purchased with the offline option. To use Diffblue Cover in an offline environment, such as a high-security or air-gapped network, requires this offline option.

Otherwise Diffblue Cover requires a 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.

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 or .

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. ->

In many cases Cover can output a 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

Manage and maintain Cover Plugin for yourself or your organization.

Start here...

Manage and maintain your Cover Reports instance.

Start here...

Next steps...

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 .

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...

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.

Manage and maintain your Cover Reports instance.

Start here...

Next steps...

To modify the Diffblue Cover settings in IntelliJ, go to Diffblue > Change Settings and update as needed.

• Test Framework: Select the test framework used for your project - JUnit 4, JUnit 5, TestNG, or Auto-Detect.

Manage and maintain Cover CLI for yourself or your organization.

Start here...

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 Gradle project. If not, follow the instructions below to add it:

1. Edit the build script (build.gradle

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>

Logging in

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

Log in to using the username and password provided in your Diffblue welcome email.

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:

Create coverage reports and improve test coverage. This learning path is targeted at developers - see the learning path for details of coverage monitoring and maintenance.

Install

1. Install Diffblue Cover Plugin for IntelliJ