Integrating Diffblue Cover into Your Existing CI/CD Pipeline

Integrating Diffblue Cover into your GitLab continuous integration/continuous delivery (CI/CD) pipeline revolutionizes the approach to maintaining high code quality in Java and Kotlin applications. Powered by artificial intelligence (AI), Diffblue Cover automates the generation of unit tests, addressing one of the most time-consuming aspects of software development.

Diffblue Cover autonomously creates appropriate unit tests, enhancing the overall test coverage and improving the robustness of the application by highlighting regressions and bugs early in the development cycle. Using the codebase’s history and development context, Diffblue Cover analyzes the codebase to:

Establish a baseline unit test suite
Craft additional unit tests for freshly written code
Revise current unit tests within the codebase
Remove any unit tests that have become unnecessary

Incorporating Diffblue Cover into your GitLab CI/CD pipeline ensures that every piece of code committed undergoes validation through meaningful auto-generated tests during merge requests. This significantly reduces the possibility of regressions throughout the development lifecycle. In this hands-on article, you’ll learn how to add Diffblue Cover into an existing GitLab pipeline.

Prerequisites for integration

For this tutorial, you’ll use this hotel management system (HMS) project on GitLab. The HMS project uses the Spring Boot framework, in-memory H2 database, Spring Data JPA, and Maven for dependency management.

The first step for integrating Diffblue Cover into a project requires an operational CI/CD pipeline within GitLab. The HMS project illustrates this prerequisite through its .gitlab-ci.yml file, outlining its existing pipeline.

The second step involves obtaining the Diffblue Cover License. Licensing is available in various tiers suitable for individual developers, teams, and enterprise-scale operations. Each license tier provides specific features and support levels, ensuring you can select the most appropriate option for your development environment.

You can obtain a license for the Diffblue Cover Teams Edition with a 14-day free trial. The license key should arrive in the email you provide when registering. Check the spam folder if you don’t get the email.

The next step is cloning and configuring the HMS project from GitLab. Here’s a concise walkthrough of the project configuration, emphasizing specific settings to ensure an error-free start.

GitLab Account — You’ll need a GitLab account to clone and interact with the project. If you don’t already have one, sign up on GitLab’s registration page.
Clone the project — Navigate to the Spring-HotelManagementSystem project on GitLab. Clone the project to your own GitLab repository.

For comprehensive guidance on running the project locally and configuring access to the H2 Database console, testing API endpoints, and other project-specific settings, refer to the README.md file within the GitLab repository. It offers valuable instructions beyond this article’s scope.

Configuring Diffblue Cover

Follow the steps outlined below to configure Diffblue Cover. By the end of this section, your Diffblue Cover integration will be active and ready for use with the HMS project.

First, you need a GitLab access token with the Developer role, along with api and write_repository permissions. They’re mandatory for enabling Diffblue Cover to access the Spring-HotelManagementSystem project.

To create a project access token on GitLab, follow these steps:

Navigate to the Spring-HotelManagementSystem project using the Search or go to feature on the left sidebar.
Go to Settings > Access Tokens through the Settings feature at the bottom of the left sidebar.
Click on Add new token to initiate the creation of a new access token.
Provide a name for the access token — for example, “HMS Diffblue Cover.” This name will be visible to anyone with project viewing permissions.
Set an expiry date for the token. Without a specified expiry date, it defaults to 30 days from the current date, with a maximum possible extension of up to 365 days from creation. For the HMS Diffblue Cover project access token, set the expiry date to 2024-05-31.
Choose a role as a Developer for the token to define its permissions level.
Select the api and write_repository scopes for the token, aligning with the specific functionalities required by Diffblue Cover.
Finalize the process by clicking Create project access token.
The HMS Diffblue Cover access token is then displayed. Be sure to save this token securely, you won’t be able to access it after navigating away or refreshing the page.

Screenshot of the Project Access Tokens page. Here, you enter the Token name, set an expiration date, select a role, and select scopes (here, api and write_repository are selected). At the bottom are two buttons: Create project access token and Cancel.

Next, access the Spring-HotelManagementSystem project within your GitLab account and navigate to Settings in the lower-left section of the project page.

Click on Settings > Integrations, and under the Add an integration section, search for “Diffblue Cover” and click on Configure. It opens a new page with the integration details required to configure Diffblue Cover, as shown below:

Screenshot of the Integration details page for Diffblue Cover. The page displays a checkbox to enable integration (selected here), a field for the license key, and fields for your access token's name and secret. At the bottom of the page are two buttons: Save changes and Cancel.

Then, follow these steps to complete the setup:

Check the Active box under the Enable integration section.
In the License key text field, paste the 25-character license key you obtained in the previous section.
Enter HMS Diffblue Cover or the name you chose for your access token in the Name text field and the access token you generated in the Secret text field.
Click Save Changes to apply these updates.

You should see an Active icon next to Diffblue Cover, indicating the integration is ready for use.

Screenshot of the Integration details page for Diffblue Cover. Beside the Diffblue Cover heading is a green active badge. The page displays a checkbox to enable integration (selected here), a field for the license key, and fields for your access token's name and secret. At the bottom of the page are two buttons: Save changes and Cancel.

Setting up the pipeline

Next, you’ll set up the Diffblue Cover pipeline with the existing .gitlab-ci.yml CI/CD pipeline in the HMS project.

First, you need to create a new branch from main named add-diffblue-cover-pipeline. This step is necessary because the diffblue-cover pipeline executes only on a merge_request_event.

Navigate to the Build > Pipeline editor to access the existing pipeline. Then, select the Browse templates option in the pipeline editor and locate the Diffblue-Cover.gitlab-ci.yml file within the GitLab template repository.

Before combining it with the Diffblue Cover pipeline, let’s review the existing CI/CD pipeline template and the configurable properties used in the file.

# Docker image with Maven and OpenJDK 17
image: maven:3.8.4-openjdk-17

# Pipeline stages
stages:
  - build
  - test

# Cache Maven dependencies
cache:
  paths:
    - .m2/repository

# Maven configuration
before_script:
  - export MAVEN_OPTS="-Dmaven.repo.local=.m2/repository"

# Build stage: compile and package
build_job:
  stage: build
  script:
    - mvn clean package -DskipTests -B
  only:
    - main
    - merge_requests

# Test stage: run tests
test_job:
  stage: test
  script:
    - mvn test
  only:
    - main
    - merge_requests

The pipeline configures automated build and testing within the GitLab CI/CD framework using Maven and JDK 17:

image sets the Docker image Maven 3.8.4 with OpenJDK 17 to run CI jobs.
stages defines two pipeline stages, build and test.
cache caches the .m2/repository directory to speed up dependency loading across pipeline runs.
before_script sets Maven options to utilize the cached repository.
build_job compiles and packages the project, executed upon commits to the main branch and merge requests.
test_job executes unit tests when code is committed on the main branch and merge requests, ensuring code quality.

Here’s the provided Diffblue Cover template you’ll use for combining with the existing pipeline:

variables:
  # Diffblue Cover requires a minimum of 4GB of memory.
  JVM_ARGS: -Xmx4g

stages:
  - build

diffblue-cover:
  stage: build

# Docker image for Diffblue Cover
  image: diffblue/cover-cli:latest-jdk17

rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'

artifacts:
    paths:
      # Save Diffblue logs as artifacts
      - "**/.diffblue/"

script:
    # Build command for Maven
    - mvn test-compile --batch-mode --no-transfer-progress

# Diffblue Cover commands
    - dcover
        ci
        activate
        validate --maven
        create --maven

This code defines a GitLab CI/CD pipeline for a Java project using Diffblue Cover. Let’s review in more detail:

image utilizes the Docker image diffblue/cover-cli:latest-jdk17 for executing CI jobs with the appropriate Java Development Kit (JDK) version.
variables sets JVM_ARGS to -Xmx4g, configuring the Java virtual machine to use a maximum of 4GB of memory, meeting Diffblue Cover’s requirements.
stages introduces a build stage, focusing on compiling and testing the project.
diffblue-cover activates during the build stage, specifically on merge request events.
artifacts is the configuration that saves Diffblue Cover log files in the .diffblue/ directory, making them available for review post-pipeline execution.
script executes Maven to compile tests, ensuring the project is ready for unit test generation and runs Diffblue Cover commands, where dcover ci integrates with GitLab CI/CD, activate enables the license, validate --maven removes tests that don’t compile or fail, and create --maven generates new unit tests using Maven.

Now, you’ll merge the Diffblue Cover pipeline template into the existing CI/CD pipeline configuration.

First, paste the variables section from the Diffblue Cover pipeline into the existing one after the Maven and OpenJDK 17 image configurable. Then, paste the diffblue-cover block from the Diffblue Cover pipeline into the existing one after the before_script configurable.

Below is the merged .gitlab-ci.yml file:

# Docker image with Maven and OpenJDK 17
image: maven:3.8.4-openjdk-17

variables:
  # Diffblue Cover requires a minimum of 4GB of memory.
  JVM_ARGS: -Xmx4g

# Pipeline stages
stages:
  - build
  - test

# Cache Maven dependencies
cache:
  paths:
    - .m2/repository

# Maven configuration
before_script:
  - export MAVEN_OPTS="-Dmaven.repo.local=.m2/repository"

# Diffblue Cover
diffblue-cover:
  stage: test

# Docker image for Diffblue Cover
  image: diffblue/cover-cli:latest-jdk17

rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'

artifacts:
    paths:
      # Save Diffblue logs as artifacts
      - "**/.diffblue/"

script:
    # Diffblue Cover commands
    - dcover
        ci
        activate
        validate --maven
        create --maven

# Build stage: compile and package
build_job:
  stage: build
  script:
    - mvn clean package -DskipTests -B
  only:
    - main
    - merge_requests

# Test stage: run tests
test_job:
  stage: test
  script:
    - mvn test
  only:
    - main
    - merge_requests

Finally, commit these changes with a commit message, such as Update .gitlab-ci.yml file. Next, initiate a merge request from the branch add-diffblue-cover-pipeline into main. This triggers the diffblue-cover pipeline.

Creating a baseline test suite

Upon creating the merge request, the merge request pipeline will execute the CI/CD pipeline along with the Diffblue Cover and create the baseline unit test suite for the project. The image below shows a snapshot of the diffblue-cover job creating tests and summarizing these test cases.

Screenshot of the diffblue-cover job creating tests and summarizing test cases within the terminal.

Beyond the baseline

With the baseline established, Cover can now use that as a guide for subsequent code changes. Now, when you initiate a merge request in GitLab, the Diffblue Cover pipeline automatically kicks off. It starts by compiling the project’s code to ensure it’s build-ready.

Next, this pipeline splits its focus. On one side, it runs existing manual unit tests to verify previous functionality. On the other hand, it uses Diffblue Cover to generate and update unit tests for the newly written code. These automated tests are a significant addition — they’re created based on the changes introduced in the merge request, enhancing the codebase’s test coverage.

After completing the tests, the pipeline merges the code and tests while also handling any potential regressions or bugs identified during the process. It ensures that every code change is thoroughly tested and validated before merging, maintaining code quality and reliability.

Flow chart outlining the steps in a Diffblue-supported, GitLab-enabled pipeline.

After the Diffblue Cover pipeline completes the execution, you can verify the generated unit tests by reviewing the src/test directory in the project repository. Look for new Java files with names suffixed with *DiffblueTest.java. These files contain the automated tests Diffblue Cover writes, tailored to your codebase’s specific changes.

Screenshot of the project repository showing the location of unit tests generated by Diffblue Cover.

Conclusion and next steps

Integrating Diffblue Cover into an existing GitLab CI/CD pipeline signifies a leap toward enhanced code quality through AI-powered unit test generation. This integration enhances code quality by automating unit test creation, ensuring thorough testing of each code commit upon merge. By aligning with continuous integration best practices, it minimizes setup requirements while reducing the risk of regressions.

Continuously adapting to code changes is vital for ongoing software project maintenance and enhancement. This iterative process helps improve features, fix bugs, and incorporate new requirements. By seamlessly merging the Diffblue Cover pipeline template with your existing CI/CD pipeline configuration, you can tailor it to suit your project’s specific needs.

Integrating Diffblue Cover into this process ensures that each change is automatically accompanied by updated or new unit tests. This approach helps maintain high code quality, catch regressions early, and ensure that new additions behave as expected without unintended side effects.

For an in-depth exploration of handling subsequent code changes with Diffblue Cover, refer to the provided guide on the GitLab workflow.

To see how Diffblue Cover can streamline your development practices and substantially (and efficiently!) improve your test coverage, explore further features and configurations.

Integrating Diffblue Cover into Your Existing CI/CD Pipeline

Author

Table of contents