Spring Cloud Contract

Spring Cloud Contract is an umbrella project holding solutions that help users in successfully implementing the Consumer Driven Contracts approach. Currently Spring Cloud Contract consists of the Spring Cloud Contract Verifier project.

Spring Cloud Contract Verifier is a tool that enables Consumer Driven Contract (CDC) development of JVM-based applications. It is shipped with Contract Definition Language (DSL) written in Groovy or YAML. Contract definitions are used to produce following resources:

by default JSON stub definitions to be used by WireMock (HTTP Server Stub) when doing integration testing on the client code (client tests). Test code must still be written by hand, test data is produced by Spring Cloud Contract Verifier.
Messaging routes if you’re using one. We’re integrating with Spring Integration, Spring Cloud Stream and Apache Camel. You can however set your own integrations if you want to.
Acceptance tests (by default in JUnit or Spock) used to verify if server-side implementation of the API is compliant with the contract (server tests). Full test is generated by Spring Cloud Contract Verifier.

Spring Cloud Contract Verifier moves TDD to the level of software architecture.

To see how Spring Cloud Contract supports other languages just check out this blog post.

Features

When trying to test an application that communicates with other services then we could do one of two things:

deploy all microservices and perform end to end tests
mock other microservices in unit / integration tests

Both have their advantages but also a lot of disadvantages. Let’s focus on the latter. Deploy all microservices and perform end to end tests

Advantages:

simulates production
tests real communication between services

Disadvantages:

to test one microservice we would have to deploy 6 microservices, a couple of databases etc.
the environment where the tests would be conducted would be locked for a single suite of tests (i.e. nobody else would be able to run the tests in the meantime).
long to run
very late feedback
extremely hard to debug

Mock other microservices in unit / integration tests

Advantages:

very fast feedback
no infrastructure requirements

Disadvantages:

the implementor of the service creates stubs thus they might have nothing to do with the reality
you can go to production with passing tests and failing production

To solve the aforementioned issues Spring Cloud Contract Verifier with Stub Runner were created. Their main idea is to give you very fast feedback, without the need to set up the whole world of microservices.

Spring Cloud Contract Verifier features:

ensure that HTTP / Messaging stubs (used when developing the client) are doing exactly what actual server-side implementation will do
promote acceptance test driven development method and Microservices architectural style
to provide a way to publish changes in contracts that are immediately visible on both sides of the communication
to generate boilerplate test code used on the server side

Spring Boot Config

On the Producer Side

To start working with Spring Cloud Contract, you can add files with REST or messaging contracts expressed in either Groovy DSL or YAML to the contracts directory, which is set by the contractsDslDir property. By default, it is $rootDir/src/test/resources/contracts.

Then you can add the Spring Cloud Contract Verifier dependency and plugin to your build file, as the following example shows:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-contract-verifier</artifactId>
    <scope>test</scope>
</dependency>

The following listing shows how to add the plugin, which should go in the build/plugins portion of the file:

<plugin>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-contract-maven-plugin</artifactId>
    <version>${spring-cloud-contract.version}</version>
    <extensions>true</extensions>
</plugin>

Running ./mvnw clean install automatically generates tests that verify the application compliance with the added contracts. By default, the tests get generated under org.springframework.cloud.contract.verifier.tests.

As the implementation of the functionalities described by the contracts is not yet present, the tests fail.

To make them pass, you must add the correct implementation of either handling HTTP requests or messages. Also, you must add a base test class for auto-generated tests to the project. This class is extended by all the auto-generated tests, and it should contain all the setup information necessary to run them (for example RestAssuredMockMvc controller setup or messaging test setup).

The following example, from pom.xml, shows how to specify the base test class:

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-contract-maven-plugin</artifactId>
            <version>${spring-cloud-contract.version}</version>
            <extensions>true</extensions>
            <configuration>
                <baseClassForTests>com.example.contractTest.BaseTestClass</baseClassForTests>
            </configuration>
        </plugin>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

INFO: The baseClassForTests element lets you specify your base test class. It must be a child of a configuration element within spring-cloud-contract-maven-plugin.

Once the implementation and the test base class are in place, the tests pass, and both the application and the stub artifacts are built and installed in the local Maven repository. You can now merge the changes, and you can publish both the application and the stub artifacts in an online repository.

On the Consumer Side

You can use Spring Cloud Contract Stub Runner in the integration tests to get a running WireMock instance or messaging route that simulates the actual service.

To do so, add the dependency to Spring Cloud Contract Stub Runner, as the following example shows:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-contract-stub-runner</artifactId>
    <scope>test</scope>
</dependency>

You can get the Producer-side stubs installed in your Maven repository in either of two ways:

By checking out the Producer side repository and adding contracts and generating the stubs by running the following commands:

$ cd local-http-server-repo
$ ./mvnw clean install -DskipTests

The tests are being skipped because the producer-side contract implementation is not in place yet, so the automatically-generated contract tests fail.

By getting already-existing producer service stubs from a remote repository. To do so, pass the stub artifact IDs and artifact repository URL as Spring Cloud Contract Stub Runner properties, as the following example shows:

    stubrunner:
      ids: 'com.example:http-server-dsl:+:stubs:8080'
      repositoryRoot: https://repo.spring.io/libs-snapshot

Now you can annotate your test class with @AutoConfigureStubRunner. In the annotation, provide the group-id and artifact-id values for Spring Cloud Contract Stub Runner to run the collaborators' stubs for you, as the following example shows:

@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment=WebEnvironment.NONE)
@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:6565"},
        stubsMode = StubRunnerProperties.StubsMode.LOCAL)
public class LoanApplicationServiceTests {

Use the REMOTE stubsMode when downloading stubs from an online repository and LOCAL for offline work.

Now, in your integration test, you can receive stubbed versions of HTTP responses or messages that are expected to be emitted by the collaborator service.

Quickstart Your Project

Bootstrap your application with Spring Initializr.

Documentation

Each Spring project has its own; it explains in great details how you can use project features and what you can achieve with them.

3.1.3 CURRENT GA	Reference Doc.
4.0.0-M3 PRE	Reference Doc.
3.1.4-SNAPSHOT SNAPSHOT	Reference Doc.
3.0.5-SNAPSHOT SNAPSHOT	Reference Doc.
3.0.4 GA	Reference Doc.
2.2.9.BUILD-SNAPSHOT SNAPSHOT	Reference Doc.
2.2.8.RELEASE GA	Reference Doc.

Branch	Initial Release	End of Support	End Commercial Support *
3.1.x	2021-11-30	2023-05-18	2024-08-22
3.0.x	2020-12-22	2022-05-19	2023-09-19
2.2.x	2019-11-26	2020-11-26	2022-03-26

OSS support

Free security updates and bugfixes with support from the Spring community. See VMware Tanzu OSS support policy.

Commercial support

Business support from Spring experts during the OSS timeline, plus extended support after OSS End-Of-Life.
Publicly available releases for critical bugfixes and security issues when requested by customers.

Future release

Generation not yet released, timeline is subject to changes.

About commercial support (*)

This page shows the current state of project releases and does not define the commercial support policy. Please refer to the official support policy for more information.

Learn more about commercial support.