Scribd
Upload
70 views

Provider Contract Testing With Stubs in Nexus or Artifactory

This document discusses different flows for using Spring Cloud Contract, including: 1. Provider contract testing with stubs stored in Nexus/Artifactory or Git. 2. Consumer driven contracts with contracts defined on the producer side or in an external repository. 3. The key steps are defining contracts, generating stubs, writing tests against stubs, and publishing stubs/contracts to a shared location for other teams. Best practices and sample projects are referenced.

Uploaded by

Jessica Paola Peña
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
70 views

Provider Contract Testing With Stubs in Nexus or Artifactory

This document discusses different flows for using Spring Cloud Contract, including: 1. Provider contract testing with stubs stored in Nexus/Artifactory or Git. 2. Consumer driven contracts with contracts defined on the producer side or in an external repository. 3. The key steps are defining contracts, generating stubs, writing tests against stubs, and publishing stubs/contracts to a shared location for other teams. Best practices and sample projects are referenced.

Uploaded by

Jessica Paola Peña
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

his section goes into more detail about how you should use Spring Cloud Contract.

It covers
topics such as flows of how to work with Spring Cloud Contract. We also cover some Spring
Cloud Contract best practices.

If you are starting out with Spring Cloud Contract, you should probably read the Getting
Started guide before diving into this section.

1. Provider Contract Testing with Stubs in Nexus or


Artifactory
You can check the Developing Your First Spring Cloud Contract based application link to
see the provider contract testing with stubs in the Nexus or Artifactory flow.

You can also check the workshop page for a step-by-step instruction on how to do this flow.

2. Provider Contract Testing with Stubs in Git


In this flow, we perform the provider contract testing (the producer has no knowledge of
how consumers use their API). The stubs are uploaded to a separate repository (they are
not uploaded to Artifactory or Nexus).

2.1. Prerequisites
Before testing provider contracts with stubs in git, you must provide a git repository that
contains all the stubs for each producer. For an example of such a project, see this
samples or this sample. As a result of pushing stubs there, the repository has the following
structure:

$ tree .
└── META-INF
└── folder.with.group.id.as.its.name
└── folder-with-artifact-id
└── folder-with-version
├── contractA.groovy
├── contractB.yml
└── contractC.groovy

You must also provide consumer code that has Spring Cloud Contract Stub Runner set up.
For an example of such a project, see this sample and search for
a BeerControllerGitTest test. You must also provide producer code that has Spring Cloud
Contract set up, together with a plugin. For an example of such a project, see this sample.

2.2. The Flow


The flow looks exactly as the one presented in Developing Your First Spring Cloud Contract
based application, but the Stub Storage implementation is a git repository.
You can read more about setting up a git repository and setting consumer and producer
side in the How To page of the documentation.

2.3. Consumer setup


In order to fetch the stubs from a git repository instead of Nexus or Artifactory, you need to
use the git protocol in the URL of the repositoryRoot property in Stub Runner. The
following example shows how to set it up:

Annotation
JUnit 4 Rule
JUnit 5 Extension
@AutoConfigureStubRunner(
stubsMode = StubRunnerProperties.StubsMode.REMOTE,
repositoryRoot = "git://[email protected]:spring-cloud-samples/spring-cloud-
contract-nodejs-contracts-git.git",
ids = "com.example:artifact-id:0.0.1")

2.4. Setting up the Producer


In order to push the stubs to a git repository instead of Nexus or Artifactory, you need to
use the git protocol in the URL of the plugin setup. Also you need to explicitly tell the
plugin to push the stubs at the end of the build process. The following example shows how
to do so:

maven
gradle
<plugin>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-contract-maven-plugin</artifactId>
<version>${spring-cloud-contract.version}</version>
<extensions>true</extensions>
<configuration>
<!-- Base class mappings etc. -->

<!-- We want to pick contracts from a Git repository -->


<contractsRepositoryUrl>git://git://[email protected]:spring-cloud-
samples/spring-cloud-contract-nodejs-contracts-git.git</contractsRepositoryUrl>

<!-- We reuse the contract dependency section to set up the path


to the folder that contains the contract definitions. In our case the
path will be /groupId/artifactId/version/contracts -->
<contractDependency>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
</contractDependency>

<!-- The contracts mode can't be classpath -->


<contractsMode>REMOTE</contractsMode>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<!-- By default we will not push the stubs back to SCM,
you have to explicitly add it as a goal -->
<goal>pushStubsToScm</goal>
</goals>
</execution>
</executions>
</plugin>

You can read more about setting up a git repository in the How To page of the
documentation.

3. Consumer Driven Contracts with Contracts on the


Producer Side
See Step-by-step Guide to Consumer Driven Contracts (CDC) with Contracts on the
Producer Side to see the Consumer Driven Contracts with contracts on the producer side
flow.

4. Consumer Driven Contracts with Contracts in an External


Repository
In this flow, we perform Consumer Driven Contract testing. The contract definitions are
stored in a separate repository.

See the workshop page for step-by-step instructions on how to do this flow.

4.1. Prerequisites
To use consumer-driven contracts with the contracts held in an external repository, you
need to set up a git repository that:

 Contains all the contract definitions for each producer.


 Can package the contract definitions in a JAR.
 For each contract producer, contains a way (for example, pom.xml) to install stubs
locally through the Spring Cloud Contract Plugin (SCC Plugin)
For more information, see the How To section, where we describe how to set up such a
repository For an example of such a project, see this sample.

You also need consumer code that has Spring Cloud Contract Stub Runner set up. For an
example of such a project, see this sample. You also need producer code that has Spring
Cloud Contract set up, together with a plugin. For an example of such a project, see this
sample. The stub storage is Nexus or Artifactory

At a high level, the flow looks as follows:

1. The consumer works with the contract definitions from the separate repository
2. Once the consumer’s work is done, a branch with working code is done on the
consumer side and a pull request is made to the separate repository that holds the
contract definitions.
3. The producer takes over the pull request to the separate repository with contract
definitions and installs the JAR with all contracts locally.
4. The producer generates tests from the locally stored JAR and writes the missing
implementation to make the tests pass.
5. Once the producer’s work is done, the pull request to the repository that holds the
contract definitions is merged.
6. After the CI tool builds the repository with the contract definitions and the JAR with
contract definitions gets uploaded to Nexus or Artifactory, the producer can merge its
branch.
7. Finally, the consumer can switch to working online to fetch stubs of the producer from
a remote location, and the branch can be merged to master.

4.2. Consumer Flow


The consumer:

1. Writes a test that would send a request to the producer.


The test fails due to no server being present.
2. Clones the repository that holds the contract definitions.
3. Set up the requirements as contracts under the folder with the consumer name as a
subfolder of the producer.
For example, for a producer named producer and a consumer named consumer, the
contracts would be stored under src/main/resources/contracts/producer/consumer/)
4. Once the contracts are defined, installs the producer stubs to local storage, as the
following exam

You might also like