From 936f1b558274baa7b60fb80a5e193ebf54dff498 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Wed, 1 Aug 2018 15:34:43 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- multi/multi__contract_dsl.html | 15 ++++- multi/multi__spring_cloud_contract_faq.html | 4 +- ..._cloud_contract_verifier_introduction.html | 41 ++++++------ ...lti__using_the_pluggable_architecture.html | 4 +- multi/multi_spring-cloud-contract.html | 2 +- single/spring-cloud-contract.html | 66 +++++++++++-------- .../plugin-management.html | 2 +- spring-cloud-contract.xml | 32 ++++++--- 8 files changed, 105 insertions(+), 61 deletions(-) diff --git a/multi/multi__contract_dsl.html b/multi/multi__contract_dsl.html index 8303a19275..24bbe04901 100644 --- a/multi/multi__contract_dsl.html +++ b/multi/multi__contract_dsl.html @@ -1628,7 +1628,20 @@ to work with Web Flux.

Maven.  // your tests go here // in this config class you define all controllers and mocked services - include::{samples_url}/producer_webflux/src/test/java/com/example/BeerRestBase.java[tags=config,indent=0] +@Configuration +@EnableAutoConfiguration +static class Config { + + @Bean + PersonCheckingService personCheckingService() { + return personToCheck -> personToCheck.age >= 20; + } + + @Bean + ProducerController producerController() { + return new ProducerController(personCheckingService()); + } +} }

8.10 Messaging Top-Level Elements

The DSL for messaging looks a little bit different than the one that focuses on HTTP. The following sections explain the differences:

8.10.1 Output Triggered by a Method

The output message can be triggered by calling a method (such as a Scheduler when a was diff --git a/multi/multi__spring_cloud_contract_faq.html b/multi/multi__spring_cloud_contract_faq.html index fcb948a7bf..806a1eb2e2 100644 --- a/multi/multi__spring_cloud_contract_faq.html +++ b/multi/multi__spring_cloud_contract_faq.html @@ -123,7 +123,7 @@ one to one to the contents of the repo.

Example of a <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <java.version>1.8</java.version> <spring-cloud-contract.version>2.1.0.BUILD-SNAPSHOT</spring-cloud-contract.version> - <spring-cloud-dependencies.version>Finchley.BUILD-SNAPSHOT</spring-cloud-dependencies.version> + <spring-cloud-release.version>Finchley.BUILD-SNAPSHOT</spring-cloud-release.version> <excludeBuildFolders>true</excludeBuildFolders> </properties> @@ -132,7 +132,7 @@ one to one to the contents of the repo.

Example of a <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> - <version>${spring-cloud-dependencies.version}</version> + <version>${spring-cloud-release.version}</version> <type>pom</type> <scope>import</scope> </dependency> diff --git a/multi/multi__spring_cloud_contract_verifier_introduction.html b/multi/multi__spring_cloud_contract_verifier_introduction.html index b65c5fea4f..8ea3b9169c 100644 --- a/multi/multi__spring_cloud_contract_verifier_introduction.html +++ b/multi/multi__spring_cloud_contract_verifier_introduction.html @@ -1,7 +1,6 @@ - 2. Spring Cloud Contract Verifier Introduction

2. Spring Cloud Contract Verifier Introduction
Prev   Next

2. Spring Cloud Contract Verifier Introduction

[Tip]Tip

The Accurest project was initially started by Marcin Grzejszczak and Jakub Kubrynski -(codearte.io)

Spring Cloud Contract Verifier enables Consumer Driven Contract (CDC) development of + 2. Spring Cloud Contract Verifier Introduction

2. Spring Cloud Contract Verifier Introduction
Prev   Next

2. Spring Cloud Contract Verifier Introduction

Spring Cloud Contract Verifier enables Consumer Driven Contract (CDC) development of JVM-based applications. It moves TDD to the level of software architecture.

Spring Cloud Contract Verifier ships with Contract Definition Language (CDL). Contract definitions are used to produce the following resources:

  • JSON stub definitions to be used by WireMock when doing integration testing on the client code (client tests). Test code must still be written by hand, and test data is @@ -9,7 +8,9 @@ produced by Spring Cloud Contract Verifier.
  • Messaging r Integration, Spring Cloud Stream, Spring AMQP, and Apache Camel. You can also set your own integrations.
  • Acceptance tests (in JUnit 4, JUnit 5 or Spock) are used to verify if server-side implementation of the API is compliant with the contract (server tests). A full test is generated by -Spring Cloud Contract Verifier.

2.1 Why a Contract Verifier?

Assume that we have a system consisting of multiple microservices:

Microservices Architecture

2.1.1 Testing issues

If we wanted to test the application in top left corner to determine whether it can +Spring Cloud Contract Verifier.

2.1 History

Before becoming Spring Cloud Contract, this project was called Accurest. +It was created by Marcin Grzejszczak and Jakub Kubrynski +from (codearte.io.

The 0.1.0 release took place on 26 Jan 2015 and it became stable with 1.0.0 release on 29 Feb 2016.

2.2 Why a Contract Verifier?

Assume that we have a system consisting of multiple microservices:

Microservices Architecture

2.2.1 Testing issues

If we wanted to test the application in top left corner to determine whether it can communicate with other services, 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.

Deploy all microservices and perform end to end tests

Advantages:

  • Simulates production.
  • Tests real communication between services.

Disadvantages:

  • To test one microservice, we have to deploy 6 microservices, a couple of databases, etc.
  • The environment where the tests run is locked for a single suite of tests (nobody else would be able to run the tests in the meantime).
  • They take a long time to run.
  • The feedback comes very late in the process.
  • They are extremely hard to debug.

Mock other microservices in unit/integration tests

Advantages:

  • They provide very fast feedback.
  • They have no infrastructure requirements.

Disadvantages:

  • The implementor of the service creates stubs that might have nothing to do with @@ -18,14 +19,14 @@ created. The main idea is to give you very fast feedback, without the need to se whole world of microservices. If you work on stubs, then the only applications you need are those that your application directly uses.

    Stubbed Services

    Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were created by the service that you’re calling. Also, if you can use them, it means that they -were tested against the producer’s side. In short, you can trust those stubs.

2.2 Purposes

The main purposes of Spring Cloud Contract Verifier with Stub Runner are:

  • To ensure that WireMock/Messaging stubs (used when developing the client) do exactly +were tested against the producer’s side. In short, you can trust those stubs.

2.3 Purposes

The main purposes of Spring Cloud Contract Verifier with Stub Runner are:

  • To ensure that WireMock/Messaging stubs (used when developing the client) do exactly what the actual server-side implementation does.
  • To promote ATDD method and Microservices architectural style.
  • To provide a way to publish changes in contracts that are immediately visible on both sides.
  • To generate boilerplate test code to be used on the server side.
[Important]Important

Spring Cloud Contract Verifier’s purpose is NOT to start writing business features in the contracts. Assume that we have a business use case of fraud check. If a user can be a fraud for 100 different reasons, we would assume that you would create 2 contracts, one for the positive case and one for the negative case. Contract tests are -used to test contracts between applications and not to simulate full behavior.

2.3 How It Works

This section explores how Spring Cloud Contract Verifier with Stub Runner works.

2.3.1 A Three-second Tour

This very brief tour walks through using Spring Cloud Contract:

You can find a somewhat longer tour -here.

On the Producer Side

To start working with Spring Cloud Contract, add files with REST/ messaging contracts +used to test contracts between applications and not to simulate full behavior.

2.4 How It Works

This section explores how Spring Cloud Contract Verifier with Stub Runner works.

2.4.1 A Three-second Tour

This very brief tour walks through using Spring Cloud Contract:

You can find a somewhat longer tour +here.

On the Producer Side

To start working with Spring Cloud Contract, add files with REST/ 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 add the Spring Cloud Contract Verifier dependency and plugin to your build file, as shown in the following example:

<dependency>
@@ -71,8 +72,8 @@ run the collaborators' stubs for you, as shown in the following example:
@DirtiesContext
 public class LoanApplicationServiceTests {
[Tip]Tip
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.

2.3.2 A Three-minute Tour

This brief tour walks through using Spring Cloud Contract:

You can find an even more brief tour -here.

On the Producer Side

To start working with Spring Cloud Contract, add files with REST/ messaging contracts +messages that are expected to be emitted by the collaborator service.

2.4.2 A Three-minute Tour

This brief tour walks through using Spring Cloud Contract:

You can find an even more brief tour +here.

On the Producer Side

To start working with Spring Cloud Contract, add files with REST/ 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.

For the HTTP stubs, a contract defines what kind of response should be returned for a given request (taking into account the HTTP methods, URLs, headers, status codes, and so @@ -240,7 +241,7 @@ to the following in the build logs:

2016-07-19 14:22:25.451  INFO 41050 --- [           main] o.s.c.c.stubrunner.AetherStubDownloader  : Resolved artifact com.example:http-server:jar:stubs:0.0.1-SNAPSHOT to /path/to/your/.m2/repository/com/example/http-server/0.0.1-SNAPSHOT/http-server-0.0.1-SNAPSHOT-stubs.jar
 2016-07-19 14:22:25.465  INFO 41050 --- [           main] o.s.c.c.stubrunner.AetherStubDownloader  : Unpacking stub from JAR [URI: file:/path/to/your/.m2/repository/com/example/http-server/0.0.1-SNAPSHOT/http-server-0.0.1-SNAPSHOT-stubs.jar]
 2016-07-19 14:22:25.475  INFO 41050 --- [           main] o.s.c.c.stubrunner.AetherStubDownloader  : Unpacked file to [/var/folders/0p/xwq47sq106x1_g3dtv6qfm940000gq/T/contracts100276532569594265]
-2016-07-19 14:22:27.737  INFO 41050 --- [           main] o.s.c.c.stubrunner.StubRunnerExecutor    : All stubs are now running RunningStubs [namesAndPorts={com.example:http-server:0.0.1-SNAPSHOT:stubs=8080}]

2.3.3 Defining the Contract

As consumers of services, we need to define what exactly we want to achieve. We need to +2016-07-19 14:22:27.737 INFO 41050 --- [ main] o.s.c.c.stubrunner.StubRunnerExecutor : All stubs are now running RunningStubs [namesAndPorts={com.example:http-server:0.0.1-SNAPSHOT:stubs=8080}]

2.4.3 Defining the Contract

As consumers of services, we need to define what exactly we want to achieve. We need to formulate our expectations. That is why we write contracts.

Assume that you want to send a request containing the ID of a client company and the amount it wants to borrow from us. You also want to send it to the /fraudcheck url via the PUT method.

Groovy DSL.  @@ -354,7 +355,7 @@ response: # (7) #(9) - and JSON body equal to # { "fraudCheckStatus": "FRAUD", "rejectionReason": "Amount too high" } #(10) - with header `Content-Type` equal to `application/json;charset=UTF-8`

-

2.3.4 Client Side

Spring Cloud Contract generates stubs, which you can use during client-side testing. +

2.4.4 Client Side

Spring Cloud Contract generates stubs, which you can use during client-side testing. You get a running WireMock instance/Messaging route that simulates the service. You would like to feed that instance with a proper stub definition.

At some point in time, you need to send a request to the Fraud Detection service.

ResponseEntity<FraudServiceResponse> response =
 		restTemplate.exchange("http://localhost:" + port + "/fraudcheck", HttpMethod.PUT,
@@ -366,7 +367,7 @@ You would like to feed that instance with a proper stub definition.
At som
 @DirtiesContext
 public class LoanApplicationServiceTests {

After that, during the tests, Spring Cloud Contract automatically finds the stubs (simulating the real service) in the Maven repository and exposes them on a configured -(or random) port.

2.3.5 Server Side

Since you are developing your stub, you need to be sure that it actually resembles your +(or random) port.

2.4.5 Server Side

Since you are developing your stub, you need to be sure that it actually resembles your concrete implementation. You cannot have a situation where your stub acts in one way and your application behaves in a different way, especially in production.

To ensure that your application behaves the way you define in your stub, tests are generated from the stub you provide.

The autogenerated test looks, more or less, like this:

@Test
@@ -387,7 +388,7 @@ generated from the stub you provide.
The autogenerated test looks, more or
         DocumentContext parsedJson = JsonPath.parse(response.getBody().asString());
         assertThatJson(parsedJson).field("['fraudCheckStatus']").matches("[A-Z]{5}");
         assertThatJson(parsedJson).field("['rejection.reason']").isEqualTo("Amount too high");
-}

2.4 Step-by-step Guide to Consumer Driven Contracts (CDC)

Consider an example of Fraud Detection and the Loan Issuance process. The business +}

2.5 Step-by-step Guide to Consumer Driven Contracts (CDC)

Consider an example of Fraud Detection and the Loan Issuance process. The business scenario is such that we want to issue loans to people but do not want them to steal from us. The current implementation of our system grants loans to everybody.

Assume that Loan Issuance is a client to the Fraud Detection server. In the current sprint, we must develop a new feature: if a client wants to borrow too much money, then @@ -396,7 +397,7 @@ Issuance has an artifact-id of http-client, and bot discuss changes while going through the process. CDC is all about communication.

The server side code is available here and the client code here.

[Tip]Tip

In this case, the producer owns the contracts. Physically, all the contract are -in the producer’s repository.

2.4.1 Technical note

If using the SNAPSHOT / Milestone / Release Candidate versions please add the +in the producer’s repository.

2.5.1 Technical note

If using the SNAPSHOT / Milestone / Release Candidate versions please add the following section to your build:

Maven.  

<repositories>
 	<repository>
@@ -458,7 +459,7 @@ following section to your build:
Maven. 
 	maven { url "http://repo.spring.io/milestone" }
 	maven { url "http://repo.spring.io/release" }
 }

-

2.4.2 Consumer side (Loan Issuance)

As a developer of the Loan Issuance service (a consumer of the Fraud Detection server), you might do the following steps:

  1. Start doing TDD by writing a test for your feature.
  2. Write the missing implementation.
  3. Clone the Fraud Detection service repository locally.
  4. Define the contract locally in the repo of Fraud Detection service.
  5. Add the Spring Cloud Contract Verifier plugin.
  6. Run the integration tests.
  7. File a pull request.
  8. Create an initial implementation.
  9. Take over the pull request.
  10. Write the missing implementation.
  11. Deploy your app.
  12. Work online.

Start doing TDD by writing a test for your feature.

@Test
+

2.5.2 Consumer side (Loan Issuance)

As a developer of the Loan Issuance service (a consumer of the Fraud Detection server), you might do the following steps:

  1. Start doing TDD by writing a test for your feature.
  2. Write the missing implementation.
  3. Clone the Fraud Detection service repository locally.
  4. Define the contract locally in the repo of Fraud Detection service.
  5. Add the Spring Cloud Contract Verifier plugin.
  6. Run the integration tests.
  7. File a pull request.
  8. Create an initial implementation.
  9. Take over the pull request.
  10. Write the missing implementation.
  11. Deploy your app.
  12. Work online.

Start doing TDD by writing a test for your feature.

@Test
 public void shouldBeRejectedDueToAbnormalLoanAmount() {
 	// given:
 	LoanApplication application = new LoanApplication(new Client("1234567890"),
@@ -644,7 +645,7 @@ Application service):
Add the Spring Cloud Co
 		<dependency>
 			<groupId>org.springframework.cloud</groupId>
 			<artifactId>spring-cloud-dependencies</artifactId>
-			<version>${spring-cloud-dependencies.version}</version>
+			<version>${spring-cloud-release-train.version}</version>
 			<type>pom</type>
 			<scope>import</scope>
 		</dependency>
@@ -672,7 +673,7 @@ with group id com.example, artifact id stubs classifier on port 8080.
File a pull request.
What you have done until now is an iterative process. You can play around with the
 contract, install it locally, and work on the consumer side until the contract works as
 you wish.
Once you are satisfied with the results and the test passes, publish a pull request to
-the server side. Currently, the consumer side work is done.

2.4.3 Producer side (Fraud Detection server)

As a developer of the Fraud Detection server (a server to the Loan Issuance service):

Create an initial implementation.

As a reminder, you can see the initial implementation here:

@RequestMapping(value = "/fraudcheck", method = PUT)
+the server side. Currently, the consumer side work is done.

2.5.3 Producer side (Fraud Detection server)

As a developer of the Fraud Detection server (a server to the Loan Issuance service):

Create an initial implementation.

As a reminder, you can see the initial implementation here:

@RequestMapping(value = "/fraudcheck", method = PUT)
 public FraudCheckResult fraudCheck(@RequestBody FraudCheck fraudCheck) {
 return new FraudCheckResult(FraudCheckStatus.OK, NO_REASON);
 }

Take over the pull request.

$ git checkout -b contract-change-pr master
@@ -764,15 +765,15 @@ Contract Verifier plugin adds the tests to the gene
 actually run those tests from your IDE.
Deploy your app.
Once you finish your work, you can deploy your change. First, merge the branch:
$ git checkout master
 $ git merge --no-ff contract-change-pr
 $ git push origin master
Your CI might run something like ./mvnw clean deploy, which would publish both the
-application and the stub artifacts.

2.4.4 Consumer Side (Loan Issuance) Final Step

As a developer of the Loan Issuance service (a consumer of the Fraud Detection server):

Merge branch to master.

$ git checkout master
+application and the stub artifacts.

2.5.4 Consumer Side (Loan Issuance) Final Step

As a developer of the Loan Issuance service (a consumer of the Fraud Detection server):

Merge branch to master.

$ git checkout master
 $ git merge --no-ff contract-change-pr

Work online.

Now you can disable the offline work for Spring Cloud Contract Stub Runner and indicate where the repository with your stubs is located. At this moment the stubs of the server side are automatically downloaded from Nexus/Artifactory. You can set the value of stubsMode to REMOTE. The following code shows an example of achieving the same thing by changing the properties.

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

That’s it!

2.5 Dependencies

The best way to add dependencies is to use the proper starter dependency.

For stub-runner, use spring-cloud-starter-stub-runner. When you use a plugin, add -spring-cloud-starter-contract-verifier.

2.6 Additional Links

Here are some resources related to Spring Cloud Contract Verifier and Stub Runner. Note + repositoryRoot: http://repo.spring.io/libs-snapshot

That’s it!

2.6 Dependencies

The best way to add dependencies is to use the proper starter dependency.

For stub-runner, use spring-cloud-starter-stub-runner. When you use a plugin, add +spring-cloud-starter-contract-verifier.

2.7 Additional Links

Here are some resources related to Spring Cloud Contract Verifier and Stub Runner. Note that some may be outdated, because the Spring Cloud Contract Verifier project is under -constant development.

2.6.1 Spring Cloud Contract video

You can check out the video from the Warsaw JUG about Spring Cloud Contract:

2.6.2 Readings

2.7 Samples

You can find some samples at +constant development.

2.7.1 Spring Cloud Contract video

You can check out the video from the Warsaw JUG about Spring Cloud Contract:

2.7.2 Readings

2.8 Samples

You can find some samples at samples.

Prev   Next
1. Spring Cloud Contract Home 3. Spring Cloud Contract FAQ
\ No newline at end of file diff --git a/multi/multi__using_the_pluggable_architecture.html b/multi/multi__using_the_pluggable_architecture.html index 4b250bde97..1461873871 100644 --- a/multi/multi__using_the_pluggable_architecture.html +++ b/multi/multi__using_the_pluggable_architecture.html @@ -421,7 +421,7 @@ to clone the repository and use it as a source of contracts to generate tests or stubs.

Either via environment variables, system properties, properties set inside the plugin or contracts repository configuration you can tweak the downloader’s behaviour. Below you can find the list of -properties

Table 10.1. SCM Stub Downloader properties

Type of a property

Name of the property

Description

* git.branch (plugin prop) +properties

Table 10.1. SCM Stub Downloader properties

Type of a property

Name of the property

Description

* git.branch (plugin prop)

* stubrunner.properties.git.branch (system prop)

* STUBRUNNER_PROPERTIES_GIT_BRANCH (env prop)

master

Which branch to checkout

* git.username (plugin prop)

* stubrunner.properties.git.username (system prop) @@ -437,7 +437,7 @@ to fetch the Pact contract definitions from the Pact Broker. Whatever is set after pact:// will be parsed as the Pact Broker URL.

Either via environment variables, system properties, properties set inside the plugin or contracts repository configuration you can tweak the downloader’s behaviour. Below you can find the list of -properties

Table 10.2. SCM Stub Downloader properties

Name of a property

Default

Description

* pactbroker.host (plugin prop) +properties

Table 10.2. SCM Stub Downloader properties

Name of a property

Default

Description

* pactbroker.host (plugin prop)

* stubrunner.properties.pactbroker.host (system prop)

* STUBRUNNER_PROPERTIES_PACTBROKER_HOST (env prop)

Host from URL passed to repositoryRoot

What is the URL of Pact Broker

* pactbroker.port (plugin prop)

* stubrunner.properties.pactbroker.port (system prop) diff --git a/multi/multi_spring-cloud-contract.html b/multi/multi_spring-cloud-contract.html index 2cc2a1a3f5..0f29967f9e 100644 --- a/multi/multi_spring-cloud-contract.html +++ b/multi/multi_spring-cloud-contract.html @@ -1,3 +1,3 @@ - Spring Cloud Contract

Spring Cloud Contract
   Next

Spring Cloud Contract

Table of Contents

1. Spring Cloud Contract
2. Spring Cloud Contract Verifier Introduction
2.1. Why a Contract Verifier?
2.1.1. Testing issues
2.2. Purposes
2.3. How It Works
2.3.1. A Three-second Tour
On the Producer Side
On the Consumer Side
2.3.2. A Three-minute Tour
On the Producer Side
On the Consumer Side
2.3.3. Defining the Contract
2.3.4. Client Side
2.3.5. Server Side
2.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
2.4.1. Technical note
2.4.2. Consumer side (Loan Issuance)
2.4.3. Producer side (Fraud Detection server)
2.4.4. Consumer Side (Loan Issuance) Final Step
2.5. Dependencies
2.6. Additional Links
2.6.1. Spring Cloud Contract video
2.6.2. Readings
2.7. Samples
3. Spring Cloud Contract FAQ
3.1. Why use Spring Cloud Contract Verifier and not X ?
3.2. I don’t want to write a contract in Groovy!
3.3. What is this value(consumer(), producer()) ?
3.4. How to do Stubs versioning?
3.4.1. API Versioning
3.4.2. JAR versioning
3.4.3. Dev or prod stubs
3.5. Common repo with contracts
3.5.1. Repo structure
3.5.2. Workflow
3.5.3. Consumer
3.5.4. Producer
3.5.5. How can I define messaging contracts per topic not per producer?
For Maven Project
For Gradle Project
3.6. Do I need a Binary Storage? Can’t I use Git?
3.6.1. Protocol convention
3.6.2. Producer
3.6.3. Consumer
3.7. Can I use the Pact Broker?
3.7.1. Pact Consumer
3.7.2. Producer
3.7.3. Pact Consumer (Producer Contract approach)
3.8. How can I debug the request/response being sent by the generated tests client?
3.8.1. How can I debug the mapping/request/response being sent by WireMock?
3.8.2. How can I see what got registered in the HTTP server stub?
3.8.3. Can I reference text from file?
4. Spring Cloud Contract Verifier Setup
4.1. Gradle Project
4.1.1. Prerequisites
4.1.2. Add Gradle Plugin with Dependencies
4.1.3. Gradle and Rest Assured 2.0
4.1.4. Snapshot Versions for Gradle
4.1.5. Add stubs
4.1.6. Run the Plugin
4.1.7. Default Setup
4.1.8. Configure Plugin
4.1.9. Configuration Options
4.1.10. Single Base Class for All Tests
4.1.11. Different Base Classes for Contracts
4.1.12. Invoking Generated Tests
4.1.13. Pushing stubs to SCM
4.1.14. Spring Cloud Contract Verifier on the Consumer Side
4.2. Maven Project
4.2.1. Add maven plugin
4.2.2. Maven and Rest Assured 2.0
4.2.3. Snapshot versions for Maven
4.2.4. Add stubs
4.2.5. Run plugin
4.2.6. Configure plugin
4.2.7. Configuration Options
4.2.8. Single Base Class for All Tests
4.2.9. Different base classes for contracts
4.2.10. Invoking generated tests
4.2.11. Pushing stubs to SCM
4.2.12. Maven Plugin and STS
4.3. Stubs and Transitive Dependencies
4.4. CI Server setup
4.5. Scenarios
4.6. Docker Project
4.6.1. Short intro to Maven, JARs and Binary storage
4.6.2. How it works
Environment Variables
4.6.3. Example of usage
4.6.4. Server side (nodejs)
5. Spring Cloud Contract Verifier Messaging
5.1. Integrations
5.2. Manual Integration Testing
5.3. Publisher-Side Test Generation
5.3.1. Scenario 1: No Input Message
5.3.2. Scenario 2: Output Triggered by Input
5.3.3. Scenario 3: No Output Message
5.4. Consumer Stub Generation
6. Spring Cloud Contract Stub Runner
6.1. Snapshot versions
6.2. Publishing Stubs as JARs
6.3. Stub Runner Core
6.3.1. Retrieving stubs
Stub downloading
Classpath scanning
6.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
6.4. Stub Runner JUnit Rule
6.4.1. Maven settings
6.4.2. Providing fixed ports
6.4.3. Fluent API
6.4.4. Stub Runner with Spring
6.5. Stub Runner Spring Cloud
6.5.1. Stubbing Service Discovery
Test profiles and service discovery
6.5.2. Additional Configuration
6.6. Stub Runner Boot Application
6.6.1. How to use it?
Stub Runner Server
Stub Runner Server Fat Jar
Spring Cloud CLI
6.6.2. Endpoints
HTTP
Messaging
6.6.3. Example
6.6.4. Stub Runner Boot with Service Discovery
6.7. Stubs Per Consumer
6.8. Common
6.8.1. Common Properties for JUnit and Spring
6.8.2. Stub Runner Stubs IDs
6.9. Stub Runner Docker
6.9.1. How to use it
6.9.2. Example of client side usage in a non JVM project
7. Stub Runner for Messaging
7.1. Stub triggering
7.1.1. Trigger by Label
7.1.2. Trigger by Group and Artifact Ids
7.1.3. Trigger by Artifact Ids
7.1.4. Trigger All Messages
7.2. Stub Runner Integration
7.2.1. Adding the Runner to the Project
7.2.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.3. Stub Runner Stream
7.3.1. Adding the Runner to the Project
7.3.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.4. Stub Runner Spring AMQP
7.4.1. Adding the Runner to the Project
Triggering the message
Spring AMQP Test Configuration
8. Contract DSL
8.1. Limitations
8.2. Common Top-Level elements
8.2.1. Description
8.2.2. Name
8.2.3. Ignoring Contracts
8.2.4. Passing Values from Files
8.2.5. HTTP Top-Level Elements
8.3. Request
8.4. Response
8.5. Dynamic properties
8.5.1. Dynamic properties inside the body
8.5.2. Regular expressions
8.5.3. Passing Optional Parameters
8.5.4. Executing Custom Methods on the Server Side
8.5.5. Referencing the Request from the Response
8.5.6. Registering Your Own WireMock Extension
8.5.7. Dynamic Properties in the Matchers Sections
8.6. JAX-RS Support
8.7. Async Support
8.8. Working with Context Paths
8.9. Working with Web Flux
8.10. Messaging Top-Level Elements
8.10.1. Output Triggered by a Method
8.10.2. Output Triggered by a Message
8.10.3. Consumer/Producer
8.10.4. Common
8.11. Multiple Contracts in One File
8.12. Generating Spring REST Docs snippets from the contracts
9. Customization
9.1. Extending the DSL
9.1.1. Common JAR
9.1.2. Adding the Dependency to the Project
9.1.3. Test the Dependency in the Project’s Dependencies
9.1.4. Test a Dependency in the Plugin’s Dependencies
9.1.5. Referencing classes in DSLs
10. Using the Pluggable Architecture
10.1. Custom Contract Converter
10.1.1. Pact Converter
10.1.2. Pact Contract
10.1.3. Pact for Producers
10.1.4. Pact for Consumers
10.2. Using the Custom Test Generator
10.3. Using the Custom Stub Generator
10.4. Using the Custom Stub Runner
10.5. Using the Custom Stub Downloader
10.6. Using the SCM Stub Downloader
10.7. Using the Pact Stub Downloader
11. Spring Cloud Contract WireMock
11.1. Registering Stubs Automatically
11.2. Using Files to Specify the Stub Bodies
11.3. Alternative: Using JUnit Rules
11.4. Relaxed SSL Validation for Rest Template
11.5. WireMock and Spring MVC Mocks
11.6. Customization of WireMock configuration
11.7. Generating Stubs using REST Docs
11.8. Generating Contracts by Using REST Docs
12. Migrations
12.1. 1.0.x → 1.1.x
12.1.1. New structure of generated stubs
12.2. 1.1.x → 1.2.x
12.2.1. Custom HttpServerStub
12.2.2. New packages for generated tests
12.2.3. New Methods in TemplateProcessor
12.2.4. RestAssured 3.0
12.3. 1.2.x → 2.0.x
12.3.1. No Camel support
13. Links
   Next
   
\ No newline at end of file + Spring Cloud Contract
Spring Cloud Contract
   Next

Spring Cloud Contract

Table of Contents

1. Spring Cloud Contract
2. Spring Cloud Contract Verifier Introduction
2.1. History
2.2. Why a Contract Verifier?
2.2.1. Testing issues
2.3. Purposes
2.4. How It Works
2.4.1. A Three-second Tour
On the Producer Side
On the Consumer Side
2.4.2. A Three-minute Tour
On the Producer Side
On the Consumer Side
2.4.3. Defining the Contract
2.4.4. Client Side
2.4.5. Server Side
2.5. Step-by-step Guide to Consumer Driven Contracts (CDC)
2.5.1. Technical note
2.5.2. Consumer side (Loan Issuance)
2.5.3. Producer side (Fraud Detection server)
2.5.4. Consumer Side (Loan Issuance) Final Step
2.6. Dependencies
2.7. Additional Links
2.7.1. Spring Cloud Contract video
2.7.2. Readings
2.8. Samples
3. Spring Cloud Contract FAQ
3.1. Why use Spring Cloud Contract Verifier and not X ?
3.2. I don’t want to write a contract in Groovy!
3.3. What is this value(consumer(), producer()) ?
3.4. How to do Stubs versioning?
3.4.1. API Versioning
3.4.2. JAR versioning
3.4.3. Dev or prod stubs
3.5. Common repo with contracts
3.5.1. Repo structure
3.5.2. Workflow
3.5.3. Consumer
3.5.4. Producer
3.5.5. How can I define messaging contracts per topic not per producer?
For Maven Project
For Gradle Project
3.6. Do I need a Binary Storage? Can’t I use Git?
3.6.1. Protocol convention
3.6.2. Producer
3.6.3. Consumer
3.7. Can I use the Pact Broker?
3.7.1. Pact Consumer
3.7.2. Producer
3.7.3. Pact Consumer (Producer Contract approach)
3.8. How can I debug the request/response being sent by the generated tests client?
3.8.1. How can I debug the mapping/request/response being sent by WireMock?
3.8.2. How can I see what got registered in the HTTP server stub?
3.8.3. Can I reference text from file?
4. Spring Cloud Contract Verifier Setup
4.1. Gradle Project
4.1.1. Prerequisites
4.1.2. Add Gradle Plugin with Dependencies
4.1.3. Gradle and Rest Assured 2.0
4.1.4. Snapshot Versions for Gradle
4.1.5. Add stubs
4.1.6. Run the Plugin
4.1.7. Default Setup
4.1.8. Configure Plugin
4.1.9. Configuration Options
4.1.10. Single Base Class for All Tests
4.1.11. Different Base Classes for Contracts
4.1.12. Invoking Generated Tests
4.1.13. Pushing stubs to SCM
4.1.14. Spring Cloud Contract Verifier on the Consumer Side
4.2. Maven Project
4.2.1. Add maven plugin
4.2.2. Maven and Rest Assured 2.0
4.2.3. Snapshot versions for Maven
4.2.4. Add stubs
4.2.5. Run plugin
4.2.6. Configure plugin
4.2.7. Configuration Options
4.2.8. Single Base Class for All Tests
4.2.9. Different base classes for contracts
4.2.10. Invoking generated tests
4.2.11. Pushing stubs to SCM
4.2.12. Maven Plugin and STS
4.3. Stubs and Transitive Dependencies
4.4. CI Server setup
4.5. Scenarios
4.6. Docker Project
4.6.1. Short intro to Maven, JARs and Binary storage
4.6.2. How it works
Environment Variables
4.6.3. Example of usage
4.6.4. Server side (nodejs)
5. Spring Cloud Contract Verifier Messaging
5.1. Integrations
5.2. Manual Integration Testing
5.3. Publisher-Side Test Generation
5.3.1. Scenario 1: No Input Message
5.3.2. Scenario 2: Output Triggered by Input
5.3.3. Scenario 3: No Output Message
5.4. Consumer Stub Generation
6. Spring Cloud Contract Stub Runner
6.1. Snapshot versions
6.2. Publishing Stubs as JARs
6.3. Stub Runner Core
6.3.1. Retrieving stubs
Stub downloading
Classpath scanning
6.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
6.4. Stub Runner JUnit Rule
6.4.1. Maven settings
6.4.2. Providing fixed ports
6.4.3. Fluent API
6.4.4. Stub Runner with Spring
6.5. Stub Runner Spring Cloud
6.5.1. Stubbing Service Discovery
Test profiles and service discovery
6.5.2. Additional Configuration
6.6. Stub Runner Boot Application
6.6.1. How to use it?
Stub Runner Server
Stub Runner Server Fat Jar
Spring Cloud CLI
6.6.2. Endpoints
HTTP
Messaging
6.6.3. Example
6.6.4. Stub Runner Boot with Service Discovery
6.7. Stubs Per Consumer
6.8. Common
6.8.1. Common Properties for JUnit and Spring
6.8.2. Stub Runner Stubs IDs
6.9. Stub Runner Docker
6.9.1. How to use it
6.9.2. Example of client side usage in a non JVM project
7. Stub Runner for Messaging
7.1. Stub triggering
7.1.1. Trigger by Label
7.1.2. Trigger by Group and Artifact Ids
7.1.3. Trigger by Artifact Ids
7.1.4. Trigger All Messages
7.2. Stub Runner Integration
7.2.1. Adding the Runner to the Project
7.2.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.3. Stub Runner Stream
7.3.1. Adding the Runner to the Project
7.3.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.4. Stub Runner Spring AMQP
7.4.1. Adding the Runner to the Project
Triggering the message
Spring AMQP Test Configuration
8. Contract DSL
8.1. Limitations
8.2. Common Top-Level elements
8.2.1. Description
8.2.2. Name
8.2.3. Ignoring Contracts
8.2.4. Passing Values from Files
8.2.5. HTTP Top-Level Elements
8.3. Request
8.4. Response
8.5. Dynamic properties
8.5.1. Dynamic properties inside the body
8.5.2. Regular expressions
8.5.3. Passing Optional Parameters
8.5.4. Executing Custom Methods on the Server Side
8.5.5. Referencing the Request from the Response
8.5.6. Registering Your Own WireMock Extension
8.5.7. Dynamic Properties in the Matchers Sections
8.6. JAX-RS Support
8.7. Async Support
8.8. Working with Context Paths
8.9. Working with Web Flux
8.10. Messaging Top-Level Elements
8.10.1. Output Triggered by a Method
8.10.2. Output Triggered by a Message
8.10.3. Consumer/Producer
8.10.4. Common
8.11. Multiple Contracts in One File
8.12. Generating Spring REST Docs snippets from the contracts
9. Customization
9.1. Extending the DSL
9.1.1. Common JAR
9.1.2. Adding the Dependency to the Project
9.1.3. Test the Dependency in the Project’s Dependencies
9.1.4. Test a Dependency in the Plugin’s Dependencies
9.1.5. Referencing classes in DSLs
10. Using the Pluggable Architecture
10.1. Custom Contract Converter
10.1.1. Pact Converter
10.1.2. Pact Contract
10.1.3. Pact for Producers
10.1.4. Pact for Consumers
10.2. Using the Custom Test Generator
10.3. Using the Custom Stub Generator
10.4. Using the Custom Stub Runner
10.5. Using the Custom Stub Downloader
10.6. Using the SCM Stub Downloader
10.7. Using the Pact Stub Downloader
11. Spring Cloud Contract WireMock
11.1. Registering Stubs Automatically
11.2. Using Files to Specify the Stub Bodies
11.3. Alternative: Using JUnit Rules
11.4. Relaxed SSL Validation for Rest Template
11.5. WireMock and Spring MVC Mocks
11.6. Customization of WireMock configuration
11.7. Generating Stubs using REST Docs
11.8. Generating Contracts by Using REST Docs
12. Migrations
12.1. 1.0.x → 1.1.x
12.1.1. New structure of generated stubs
12.2. 1.1.x → 1.2.x
12.2.1. Custom HttpServerStub
12.2.2. New packages for generated tests
12.2.3. New Methods in TemplateProcessor
12.2.4. RestAssured 3.0
12.3. 1.2.x → 2.0.x
12.3.1. No Camel support
13. Links
   Next
   
\ No newline at end of file diff --git a/single/spring-cloud-contract.html b/single/spring-cloud-contract.html index 7e208a7352..c4bf5d79da 100644 --- a/single/spring-cloud-contract.html +++ b/single/spring-cloud-contract.html @@ -1,12 +1,11 @@ - Spring Cloud Contract

Spring Cloud Contract

Table of Contents

1. Spring Cloud Contract
2. Spring Cloud Contract Verifier Introduction
2.1. Why a Contract Verifier?
2.1.1. Testing issues
2.2. Purposes
2.3. How It Works
2.3.1. A Three-second Tour
On the Producer Side
On the Consumer Side
2.3.2. A Three-minute Tour
On the Producer Side
On the Consumer Side
2.3.3. Defining the Contract
2.3.4. Client Side
2.3.5. Server Side
2.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
2.4.1. Technical note
2.4.2. Consumer side (Loan Issuance)
2.4.3. Producer side (Fraud Detection server)
2.4.4. Consumer Side (Loan Issuance) Final Step
2.5. Dependencies
2.6. Additional Links
2.6.1. Spring Cloud Contract video
2.6.2. Readings
2.7. Samples
3. Spring Cloud Contract FAQ
3.1. Why use Spring Cloud Contract Verifier and not X ?
3.2. I don’t want to write a contract in Groovy!
3.3. What is this value(consumer(), producer()) ?
3.4. How to do Stubs versioning?
3.4.1. API Versioning
3.4.2. JAR versioning
3.4.3. Dev or prod stubs
3.5. Common repo with contracts
3.5.1. Repo structure
3.5.2. Workflow
3.5.3. Consumer
3.5.4. Producer
3.5.5. How can I define messaging contracts per topic not per producer?
For Maven Project
For Gradle Project
3.6. Do I need a Binary Storage? Can’t I use Git?
3.6.1. Protocol convention
3.6.2. Producer
3.6.3. Consumer
3.7. Can I use the Pact Broker?
3.7.1. Pact Consumer
3.7.2. Producer
3.7.3. Pact Consumer (Producer Contract approach)
3.8. How can I debug the request/response being sent by the generated tests client?
3.8.1. How can I debug the mapping/request/response being sent by WireMock?
3.8.2. How can I see what got registered in the HTTP server stub?
3.8.3. Can I reference text from file?
4. Spring Cloud Contract Verifier Setup
4.1. Gradle Project
4.1.1. Prerequisites
4.1.2. Add Gradle Plugin with Dependencies
4.1.3. Gradle and Rest Assured 2.0
4.1.4. Snapshot Versions for Gradle
4.1.5. Add stubs
4.1.6. Run the Plugin
4.1.7. Default Setup
4.1.8. Configure Plugin
4.1.9. Configuration Options
4.1.10. Single Base Class for All Tests
4.1.11. Different Base Classes for Contracts
4.1.12. Invoking Generated Tests
4.1.13. Pushing stubs to SCM
4.1.14. Spring Cloud Contract Verifier on the Consumer Side
4.2. Maven Project
4.2.1. Add maven plugin
4.2.2. Maven and Rest Assured 2.0
4.2.3. Snapshot versions for Maven
4.2.4. Add stubs
4.2.5. Run plugin
4.2.6. Configure plugin
4.2.7. Configuration Options
4.2.8. Single Base Class for All Tests
4.2.9. Different base classes for contracts
4.2.10. Invoking generated tests
4.2.11. Pushing stubs to SCM
4.2.12. Maven Plugin and STS
4.3. Stubs and Transitive Dependencies
4.4. CI Server setup
4.5. Scenarios
4.6. Docker Project
4.6.1. Short intro to Maven, JARs and Binary storage
4.6.2. How it works
Environment Variables
4.6.3. Example of usage
4.6.4. Server side (nodejs)
5. Spring Cloud Contract Verifier Messaging
5.1. Integrations
5.2. Manual Integration Testing
5.3. Publisher-Side Test Generation
5.3.1. Scenario 1: No Input Message
5.3.2. Scenario 2: Output Triggered by Input
5.3.3. Scenario 3: No Output Message
5.4. Consumer Stub Generation
6. Spring Cloud Contract Stub Runner
6.1. Snapshot versions
6.2. Publishing Stubs as JARs
6.3. Stub Runner Core
6.3.1. Retrieving stubs
Stub downloading
Classpath scanning
6.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
6.4. Stub Runner JUnit Rule
6.4.1. Maven settings
6.4.2. Providing fixed ports
6.4.3. Fluent API
6.4.4. Stub Runner with Spring
6.5. Stub Runner Spring Cloud
6.5.1. Stubbing Service Discovery
Test profiles and service discovery
6.5.2. Additional Configuration
6.6. Stub Runner Boot Application
6.6.1. How to use it?
Stub Runner Server
Stub Runner Server Fat Jar
Spring Cloud CLI
6.6.2. Endpoints
HTTP
Messaging
6.6.3. Example
6.6.4. Stub Runner Boot with Service Discovery
6.7. Stubs Per Consumer
6.8. Common
6.8.1. Common Properties for JUnit and Spring
6.8.2. Stub Runner Stubs IDs
6.9. Stub Runner Docker
6.9.1. How to use it
6.9.2. Example of client side usage in a non JVM project
7. Stub Runner for Messaging
7.1. Stub triggering
7.1.1. Trigger by Label
7.1.2. Trigger by Group and Artifact Ids
7.1.3. Trigger by Artifact Ids
7.1.4. Trigger All Messages
7.2. Stub Runner Integration
7.2.1. Adding the Runner to the Project
7.2.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.3. Stub Runner Stream
7.3.1. Adding the Runner to the Project
7.3.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.4. Stub Runner Spring AMQP
7.4.1. Adding the Runner to the Project
Triggering the message
Spring AMQP Test Configuration
8. Contract DSL
8.1. Limitations
8.2. Common Top-Level elements
8.2.1. Description
8.2.2. Name
8.2.3. Ignoring Contracts
8.2.4. Passing Values from Files
8.2.5. HTTP Top-Level Elements
8.3. Request
8.4. Response
8.5. Dynamic properties
8.5.1. Dynamic properties inside the body
8.5.2. Regular expressions
8.5.3. Passing Optional Parameters
8.5.4. Executing Custom Methods on the Server Side
8.5.5. Referencing the Request from the Response
8.5.6. Registering Your Own WireMock Extension
8.5.7. Dynamic Properties in the Matchers Sections
8.6. JAX-RS Support
8.7. Async Support
8.8. Working with Context Paths
8.9. Working with Web Flux
8.10. Messaging Top-Level Elements
8.10.1. Output Triggered by a Method
8.10.2. Output Triggered by a Message
8.10.3. Consumer/Producer
8.10.4. Common
8.11. Multiple Contracts in One File
8.12. Generating Spring REST Docs snippets from the contracts
9. Customization
9.1. Extending the DSL
9.1.1. Common JAR
9.1.2. Adding the Dependency to the Project
9.1.3. Test the Dependency in the Project’s Dependencies
9.1.4. Test a Dependency in the Plugin’s Dependencies
9.1.5. Referencing classes in DSLs
10. Using the Pluggable Architecture
10.1. Custom Contract Converter
10.1.1. Pact Converter
10.1.2. Pact Contract
10.1.3. Pact for Producers
10.1.4. Pact for Consumers
10.2. Using the Custom Test Generator
10.3. Using the Custom Stub Generator
10.4. Using the Custom Stub Runner
10.5. Using the Custom Stub Downloader
10.6. Using the SCM Stub Downloader
10.7. Using the Pact Stub Downloader
11. Spring Cloud Contract WireMock
11.1. Registering Stubs Automatically
11.2. Using Files to Specify the Stub Bodies
11.3. Alternative: Using JUnit Rules
11.4. Relaxed SSL Validation for Rest Template
11.5. WireMock and Spring MVC Mocks
11.6. Customization of WireMock configuration
11.7. Generating Stubs using REST Docs
11.8. Generating Contracts by Using REST Docs
12. Migrations
12.1. 1.0.x → 1.1.x
12.1.1. New structure of generated stubs
12.2. 1.1.x → 1.2.x
12.2.1. Custom HttpServerStub
12.2.2. New packages for generated tests
12.2.3. New Methods in TemplateProcessor
12.2.4. RestAssured 3.0
12.3. 1.2.x → 2.0.x
12.3.1. No Camel support
13. Links

Documentation Authors: Adam Dudczak, Mathias Düsterhöft, Marcin Grzejszczak, Dennis Kieselhorst, Jakub Kubryński, Karol Lassak, + Spring Cloud Contract

Spring Cloud Contract

Table of Contents

1. Spring Cloud Contract
2. Spring Cloud Contract Verifier Introduction
2.1. History
2.2. Why a Contract Verifier?
2.2.1. Testing issues
2.3. Purposes
2.4. How It Works
2.4.1. A Three-second Tour
On the Producer Side
On the Consumer Side
2.4.2. A Three-minute Tour
On the Producer Side
On the Consumer Side
2.4.3. Defining the Contract
2.4.4. Client Side
2.4.5. Server Side
2.5. Step-by-step Guide to Consumer Driven Contracts (CDC)
2.5.1. Technical note
2.5.2. Consumer side (Loan Issuance)
2.5.3. Producer side (Fraud Detection server)
2.5.4. Consumer Side (Loan Issuance) Final Step
2.6. Dependencies
2.7. Additional Links
2.7.1. Spring Cloud Contract video
2.7.2. Readings
2.8. Samples
3. Spring Cloud Contract FAQ
3.1. Why use Spring Cloud Contract Verifier and not X ?
3.2. I don’t want to write a contract in Groovy!
3.3. What is this value(consumer(), producer()) ?
3.4. How to do Stubs versioning?
3.4.1. API Versioning
3.4.2. JAR versioning
3.4.3. Dev or prod stubs
3.5. Common repo with contracts
3.5.1. Repo structure
3.5.2. Workflow
3.5.3. Consumer
3.5.4. Producer
3.5.5. How can I define messaging contracts per topic not per producer?
For Maven Project
For Gradle Project
3.6. Do I need a Binary Storage? Can’t I use Git?
3.6.1. Protocol convention
3.6.2. Producer
3.6.3. Consumer
3.7. Can I use the Pact Broker?
3.7.1. Pact Consumer
3.7.2. Producer
3.7.3. Pact Consumer (Producer Contract approach)
3.8. How can I debug the request/response being sent by the generated tests client?
3.8.1. How can I debug the mapping/request/response being sent by WireMock?
3.8.2. How can I see what got registered in the HTTP server stub?
3.8.3. Can I reference text from file?
4. Spring Cloud Contract Verifier Setup
4.1. Gradle Project
4.1.1. Prerequisites
4.1.2. Add Gradle Plugin with Dependencies
4.1.3. Gradle and Rest Assured 2.0
4.1.4. Snapshot Versions for Gradle
4.1.5. Add stubs
4.1.6. Run the Plugin
4.1.7. Default Setup
4.1.8. Configure Plugin
4.1.9. Configuration Options
4.1.10. Single Base Class for All Tests
4.1.11. Different Base Classes for Contracts
4.1.12. Invoking Generated Tests
4.1.13. Pushing stubs to SCM
4.1.14. Spring Cloud Contract Verifier on the Consumer Side
4.2. Maven Project
4.2.1. Add maven plugin
4.2.2. Maven and Rest Assured 2.0
4.2.3. Snapshot versions for Maven
4.2.4. Add stubs
4.2.5. Run plugin
4.2.6. Configure plugin
4.2.7. Configuration Options
4.2.8. Single Base Class for All Tests
4.2.9. Different base classes for contracts
4.2.10. Invoking generated tests
4.2.11. Pushing stubs to SCM
4.2.12. Maven Plugin and STS
4.3. Stubs and Transitive Dependencies
4.4. CI Server setup
4.5. Scenarios
4.6. Docker Project
4.6.1. Short intro to Maven, JARs and Binary storage
4.6.2. How it works
Environment Variables
4.6.3. Example of usage
4.6.4. Server side (nodejs)
5. Spring Cloud Contract Verifier Messaging
5.1. Integrations
5.2. Manual Integration Testing
5.3. Publisher-Side Test Generation
5.3.1. Scenario 1: No Input Message
5.3.2. Scenario 2: Output Triggered by Input
5.3.3. Scenario 3: No Output Message
5.4. Consumer Stub Generation
6. Spring Cloud Contract Stub Runner
6.1. Snapshot versions
6.2. Publishing Stubs as JARs
6.3. Stub Runner Core
6.3.1. Retrieving stubs
Stub downloading
Classpath scanning
6.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
6.4. Stub Runner JUnit Rule
6.4.1. Maven settings
6.4.2. Providing fixed ports
6.4.3. Fluent API
6.4.4. Stub Runner with Spring
6.5. Stub Runner Spring Cloud
6.5.1. Stubbing Service Discovery
Test profiles and service discovery
6.5.2. Additional Configuration
6.6. Stub Runner Boot Application
6.6.1. How to use it?
Stub Runner Server
Stub Runner Server Fat Jar
Spring Cloud CLI
6.6.2. Endpoints
HTTP
Messaging
6.6.3. Example
6.6.4. Stub Runner Boot with Service Discovery
6.7. Stubs Per Consumer
6.8. Common
6.8.1. Common Properties for JUnit and Spring
6.8.2. Stub Runner Stubs IDs
6.9. Stub Runner Docker
6.9.1. How to use it
6.9.2. Example of client side usage in a non JVM project
7. Stub Runner for Messaging
7.1. Stub triggering
7.1.1. Trigger by Label
7.1.2. Trigger by Group and Artifact Ids
7.1.3. Trigger by Artifact Ids
7.1.4. Trigger All Messages
7.2. Stub Runner Integration
7.2.1. Adding the Runner to the Project
7.2.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.3. Stub Runner Stream
7.3.1. Adding the Runner to the Project
7.3.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.4. Stub Runner Spring AMQP
7.4.1. Adding the Runner to the Project
Triggering the message
Spring AMQP Test Configuration
8. Contract DSL
8.1. Limitations
8.2. Common Top-Level elements
8.2.1. Description
8.2.2. Name
8.2.3. Ignoring Contracts
8.2.4. Passing Values from Files
8.2.5. HTTP Top-Level Elements
8.3. Request
8.4. Response
8.5. Dynamic properties
8.5.1. Dynamic properties inside the body
8.5.2. Regular expressions
8.5.3. Passing Optional Parameters
8.5.4. Executing Custom Methods on the Server Side
8.5.5. Referencing the Request from the Response
8.5.6. Registering Your Own WireMock Extension
8.5.7. Dynamic Properties in the Matchers Sections
8.6. JAX-RS Support
8.7. Async Support
8.8. Working with Context Paths
8.9. Working with Web Flux
8.10. Messaging Top-Level Elements
8.10.1. Output Triggered by a Method
8.10.2. Output Triggered by a Message
8.10.3. Consumer/Producer
8.10.4. Common
8.11. Multiple Contracts in One File
8.12. Generating Spring REST Docs snippets from the contracts
9. Customization
9.1. Extending the DSL
9.1.1. Common JAR
9.1.2. Adding the Dependency to the Project
9.1.3. Test the Dependency in the Project’s Dependencies
9.1.4. Test a Dependency in the Plugin’s Dependencies
9.1.5. Referencing classes in DSLs
10. Using the Pluggable Architecture
10.1. Custom Contract Converter
10.1.1. Pact Converter
10.1.2. Pact Contract
10.1.3. Pact for Producers
10.1.4. Pact for Consumers
10.2. Using the Custom Test Generator
10.3. Using the Custom Stub Generator
10.4. Using the Custom Stub Runner
10.5. Using the Custom Stub Downloader
10.6. Using the SCM Stub Downloader
10.7. Using the Pact Stub Downloader
11. Spring Cloud Contract WireMock
11.1. Registering Stubs Automatically
11.2. Using Files to Specify the Stub Bodies
11.3. Alternative: Using JUnit Rules
11.4. Relaxed SSL Validation for Rest Template
11.5. WireMock and Spring MVC Mocks
11.6. Customization of WireMock configuration
11.7. Generating Stubs using REST Docs
11.8. Generating Contracts by Using REST Docs
12. Migrations
12.1. 1.0.x → 1.1.x
12.1.1. New structure of generated stubs
12.2. 1.1.x → 1.2.x
12.2.1. Custom HttpServerStub
12.2.2. New packages for generated tests
12.2.3. New Methods in TemplateProcessor
12.2.4. RestAssured 3.0
12.3. 1.2.x → 2.0.x
12.3.1. No Camel support
13. Links

Documentation Authors: Adam Dudczak, Mathias Düsterhöft, Marcin Grzejszczak, Dennis Kieselhorst, Jakub Kubryński, Karol Lassak, Olga Maciaszek-Sharma, Mariusz Smykuła, Dave Syer, Jay Bryant

2.1.0.BUILD-SNAPSHOT

1. Spring Cloud Contract

You need confidence when pushing new features to a new application or service in a distributed system. This project provides support for Consumer Driven Contracts and service schemas in Spring applications (for both HTTP and message-based interactions), covering a range of options for writing tests, publishing them as assets, and asserting -that a contract is kept by producers and consumers.

2. Spring Cloud Contract Verifier Introduction

[Tip]Tip

The Accurest project was initially started by Marcin Grzejszczak and Jakub Kubrynski -(codearte.io)

Spring Cloud Contract Verifier enables Consumer Driven Contract (CDC) development of +that a contract is kept by producers and consumers.

2. Spring Cloud Contract Verifier Introduction

Spring Cloud Contract Verifier enables Consumer Driven Contract (CDC) development of JVM-based applications. It moves TDD to the level of software architecture.

Spring Cloud Contract Verifier ships with Contract Definition Language (CDL). Contract definitions are used to produce the following resources:

  • JSON stub definitions to be used by WireMock when doing integration testing on the client code (client tests). Test code must still be written by hand, and test data is @@ -14,7 +13,9 @@ produced by Spring Cloud Contract Verifier.
  • Messaging r Integration, Spring Cloud Stream, Spring AMQP, and Apache Camel. You can also set your own integrations.
  • Acceptance tests (in JUnit 4, JUnit 5 or Spock) are used to verify if server-side implementation of the API is compliant with the contract (server tests). A full test is generated by -Spring Cloud Contract Verifier.

2.1 Why a Contract Verifier?

Assume that we have a system consisting of multiple microservices:

Microservices Architecture

2.1.1 Testing issues

If we wanted to test the application in top left corner to determine whether it can +Spring Cloud Contract Verifier.

2.1 History

Before becoming Spring Cloud Contract, this project was called Accurest. +It was created by Marcin Grzejszczak and Jakub Kubrynski +from (codearte.io.

The 0.1.0 release took place on 26 Jan 2015 and it became stable with 1.0.0 release on 29 Feb 2016.

2.2 Why a Contract Verifier?

Assume that we have a system consisting of multiple microservices:

Microservices Architecture

2.2.1 Testing issues

If we wanted to test the application in top left corner to determine whether it can communicate with other services, 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.

Deploy all microservices and perform end to end tests

Advantages:

  • Simulates production.
  • Tests real communication between services.

Disadvantages:

  • To test one microservice, we have to deploy 6 microservices, a couple of databases, etc.
  • The environment where the tests run is locked for a single suite of tests (nobody else would be able to run the tests in the meantime).
  • They take a long time to run.
  • The feedback comes very late in the process.
  • They are extremely hard to debug.

Mock other microservices in unit/integration tests

Advantages:

  • They provide very fast feedback.
  • They have no infrastructure requirements.

Disadvantages:

  • The implementor of the service creates stubs that might have nothing to do with @@ -23,14 +24,14 @@ created. The main idea is to give you very fast feedback, without the need to se whole world of microservices. If you work on stubs, then the only applications you need are those that your application directly uses.

    Stubbed Services

    Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were created by the service that you’re calling. Also, if you can use them, it means that they -were tested against the producer’s side. In short, you can trust those stubs.

2.2 Purposes

The main purposes of Spring Cloud Contract Verifier with Stub Runner are:

  • To ensure that WireMock/Messaging stubs (used when developing the client) do exactly +were tested against the producer’s side. In short, you can trust those stubs.

2.3 Purposes

The main purposes of Spring Cloud Contract Verifier with Stub Runner are:

  • To ensure that WireMock/Messaging stubs (used when developing the client) do exactly what the actual server-side implementation does.
  • To promote ATDD method and Microservices architectural style.
  • To provide a way to publish changes in contracts that are immediately visible on both sides.
  • To generate boilerplate test code to be used on the server side.
[Important]Important

Spring Cloud Contract Verifier’s purpose is NOT to start writing business features in the contracts. Assume that we have a business use case of fraud check. If a user can be a fraud for 100 different reasons, we would assume that you would create 2 contracts, one for the positive case and one for the negative case. Contract tests are -used to test contracts between applications and not to simulate full behavior.

2.3 How It Works

This section explores how Spring Cloud Contract Verifier with Stub Runner works.

2.3.1 A Three-second Tour

This very brief tour walks through using Spring Cloud Contract:

You can find a somewhat longer tour -here.

On the Producer Side

To start working with Spring Cloud Contract, add files with REST/ messaging contracts +used to test contracts between applications and not to simulate full behavior.

2.4 How It Works

This section explores how Spring Cloud Contract Verifier with Stub Runner works.

2.4.1 A Three-second Tour

This very brief tour walks through using Spring Cloud Contract:

You can find a somewhat longer tour +here.

On the Producer Side

To start working with Spring Cloud Contract, add files with REST/ 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 add the Spring Cloud Contract Verifier dependency and plugin to your build file, as shown in the following example:

<dependency>
@@ -76,8 +77,8 @@ run the collaborators' stubs for you, as shown in the following example:
@DirtiesContext
 public class LoanApplicationServiceTests {
[Tip]Tip
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.

2.3.2 A Three-minute Tour

This brief tour walks through using Spring Cloud Contract:

You can find an even more brief tour -here.

On the Producer Side

To start working with Spring Cloud Contract, add files with REST/ messaging contracts +messages that are expected to be emitted by the collaborator service.

2.4.2 A Three-minute Tour

This brief tour walks through using Spring Cloud Contract:

You can find an even more brief tour +here.

On the Producer Side

To start working with Spring Cloud Contract, add files with REST/ 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.

For the HTTP stubs, a contract defines what kind of response should be returned for a given request (taking into account the HTTP methods, URLs, headers, status codes, and so @@ -245,7 +246,7 @@ to the following in the build logs:

2016-07-19 14:22:25.451  INFO 41050 --- [           main] o.s.c.c.stubrunner.AetherStubDownloader  : Resolved artifact com.example:http-server:jar:stubs:0.0.1-SNAPSHOT to /path/to/your/.m2/repository/com/example/http-server/0.0.1-SNAPSHOT/http-server-0.0.1-SNAPSHOT-stubs.jar
 2016-07-19 14:22:25.465  INFO 41050 --- [           main] o.s.c.c.stubrunner.AetherStubDownloader  : Unpacking stub from JAR [URI: file:/path/to/your/.m2/repository/com/example/http-server/0.0.1-SNAPSHOT/http-server-0.0.1-SNAPSHOT-stubs.jar]
 2016-07-19 14:22:25.475  INFO 41050 --- [           main] o.s.c.c.stubrunner.AetherStubDownloader  : Unpacked file to [/var/folders/0p/xwq47sq106x1_g3dtv6qfm940000gq/T/contracts100276532569594265]
-2016-07-19 14:22:27.737  INFO 41050 --- [           main] o.s.c.c.stubrunner.StubRunnerExecutor    : All stubs are now running RunningStubs [namesAndPorts={com.example:http-server:0.0.1-SNAPSHOT:stubs=8080}]

2.3.3 Defining the Contract

As consumers of services, we need to define what exactly we want to achieve. We need to +2016-07-19 14:22:27.737 INFO 41050 --- [ main] o.s.c.c.stubrunner.StubRunnerExecutor : All stubs are now running RunningStubs [namesAndPorts={com.example:http-server:0.0.1-SNAPSHOT:stubs=8080}]

2.4.3 Defining the Contract

As consumers of services, we need to define what exactly we want to achieve. We need to formulate our expectations. That is why we write contracts.

Assume that you want to send a request containing the ID of a client company and the amount it wants to borrow from us. You also want to send it to the /fraudcheck url via the PUT method.

Groovy DSL.  @@ -359,7 +360,7 @@ response: # (7) #(9) - and JSON body equal to # { "fraudCheckStatus": "FRAUD", "rejectionReason": "Amount too high" } #(10) - with header `Content-Type` equal to `application/json;charset=UTF-8`

-

2.3.4 Client Side

Spring Cloud Contract generates stubs, which you can use during client-side testing. +

2.4.4 Client Side

Spring Cloud Contract generates stubs, which you can use during client-side testing. You get a running WireMock instance/Messaging route that simulates the service. You would like to feed that instance with a proper stub definition.

At some point in time, you need to send a request to the Fraud Detection service.

ResponseEntity<FraudServiceResponse> response =
 		restTemplate.exchange("http://localhost:" + port + "/fraudcheck", HttpMethod.PUT,
@@ -371,7 +372,7 @@ You would like to feed that instance with a proper stub definition.
At som
 @DirtiesContext
 public class LoanApplicationServiceTests {

After that, during the tests, Spring Cloud Contract automatically finds the stubs (simulating the real service) in the Maven repository and exposes them on a configured -(or random) port.

2.3.5 Server Side

Since you are developing your stub, you need to be sure that it actually resembles your +(or random) port.

2.4.5 Server Side

Since you are developing your stub, you need to be sure that it actually resembles your concrete implementation. You cannot have a situation where your stub acts in one way and your application behaves in a different way, especially in production.

To ensure that your application behaves the way you define in your stub, tests are generated from the stub you provide.

The autogenerated test looks, more or less, like this:

@Test
@@ -392,7 +393,7 @@ generated from the stub you provide.
The autogenerated test looks, more or
         DocumentContext parsedJson = JsonPath.parse(response.getBody().asString());
         assertThatJson(parsedJson).field("['fraudCheckStatus']").matches("[A-Z]{5}");
         assertThatJson(parsedJson).field("['rejection.reason']").isEqualTo("Amount too high");
-}

2.4 Step-by-step Guide to Consumer Driven Contracts (CDC)

Consider an example of Fraud Detection and the Loan Issuance process. The business +}

2.5 Step-by-step Guide to Consumer Driven Contracts (CDC)

Consider an example of Fraud Detection and the Loan Issuance process. The business scenario is such that we want to issue loans to people but do not want them to steal from us. The current implementation of our system grants loans to everybody.

Assume that Loan Issuance is a client to the Fraud Detection server. In the current sprint, we must develop a new feature: if a client wants to borrow too much money, then @@ -401,7 +402,7 @@ Issuance has an artifact-id of http-client, and bot discuss changes while going through the process. CDC is all about communication.

The server side code is available here and the client code here.

[Tip]Tip

In this case, the producer owns the contracts. Physically, all the contract are -in the producer’s repository.

2.4.1 Technical note

If using the SNAPSHOT / Milestone / Release Candidate versions please add the +in the producer’s repository.

2.5.1 Technical note

If using the SNAPSHOT / Milestone / Release Candidate versions please add the following section to your build:

Maven.  

<repositories>
 	<repository>
@@ -463,7 +464,7 @@ following section to your build:
Maven. 
 	maven { url "http://repo.spring.io/milestone" }
 	maven { url "http://repo.spring.io/release" }
 }

-

2.4.2 Consumer side (Loan Issuance)

As a developer of the Loan Issuance service (a consumer of the Fraud Detection server), you might do the following steps:

  1. Start doing TDD by writing a test for your feature.
  2. Write the missing implementation.
  3. Clone the Fraud Detection service repository locally.
  4. Define the contract locally in the repo of Fraud Detection service.
  5. Add the Spring Cloud Contract Verifier plugin.
  6. Run the integration tests.
  7. File a pull request.
  8. Create an initial implementation.
  9. Take over the pull request.
  10. Write the missing implementation.
  11. Deploy your app.
  12. Work online.

Start doing TDD by writing a test for your feature.

@Test
+

2.5.2 Consumer side (Loan Issuance)

As a developer of the Loan Issuance service (a consumer of the Fraud Detection server), you might do the following steps:

  1. Start doing TDD by writing a test for your feature.
  2. Write the missing implementation.
  3. Clone the Fraud Detection service repository locally.
  4. Define the contract locally in the repo of Fraud Detection service.
  5. Add the Spring Cloud Contract Verifier plugin.
  6. Run the integration tests.
  7. File a pull request.
  8. Create an initial implementation.
  9. Take over the pull request.
  10. Write the missing implementation.
  11. Deploy your app.
  12. Work online.

Start doing TDD by writing a test for your feature.

@Test
 public void shouldBeRejectedDueToAbnormalLoanAmount() {
 	// given:
 	LoanApplication application = new LoanApplication(new Client("1234567890"),
@@ -649,7 +650,7 @@ Application service):
Add the Spring Cloud Co
 		<dependency>
 			<groupId>org.springframework.cloud</groupId>
 			<artifactId>spring-cloud-dependencies</artifactId>
-			<version>${spring-cloud-dependencies.version}</version>
+			<version>${spring-cloud-release-train.version}</version>
 			<type>pom</type>
 			<scope>import</scope>
 		</dependency>
@@ -677,7 +678,7 @@ with group id com.example, artifact id stubs classifier on port 8080.
File a pull request.
What you have done until now is an iterative process. You can play around with the
 contract, install it locally, and work on the consumer side until the contract works as
 you wish.
Once you are satisfied with the results and the test passes, publish a pull request to
-the server side. Currently, the consumer side work is done.

2.4.3 Producer side (Fraud Detection server)

As a developer of the Fraud Detection server (a server to the Loan Issuance service):

Create an initial implementation.

As a reminder, you can see the initial implementation here:

@RequestMapping(value = "/fraudcheck", method = PUT)
+the server side. Currently, the consumer side work is done.

2.5.3 Producer side (Fraud Detection server)

As a developer of the Fraud Detection server (a server to the Loan Issuance service):

Create an initial implementation.

As a reminder, you can see the initial implementation here:

@RequestMapping(value = "/fraudcheck", method = PUT)
 public FraudCheckResult fraudCheck(@RequestBody FraudCheck fraudCheck) {
 return new FraudCheckResult(FraudCheckStatus.OK, NO_REASON);
 }

Take over the pull request.

$ git checkout -b contract-change-pr master
@@ -769,17 +770,17 @@ Contract Verifier plugin adds the tests to the gene
 actually run those tests from your IDE.
Deploy your app.
Once you finish your work, you can deploy your change. First, merge the branch:
$ git checkout master
 $ git merge --no-ff contract-change-pr
 $ git push origin master
Your CI might run something like ./mvnw clean deploy, which would publish both the
-application and the stub artifacts.

2.4.4 Consumer Side (Loan Issuance) Final Step

As a developer of the Loan Issuance service (a consumer of the Fraud Detection server):

Merge branch to master.

$ git checkout master
+application and the stub artifacts.

2.5.4 Consumer Side (Loan Issuance) Final Step

As a developer of the Loan Issuance service (a consumer of the Fraud Detection server):

Merge branch to master.

$ git checkout master
 $ git merge --no-ff contract-change-pr

Work online.

Now you can disable the offline work for Spring Cloud Contract Stub Runner and indicate where the repository with your stubs is located. At this moment the stubs of the server side are automatically downloaded from Nexus/Artifactory. You can set the value of stubsMode to REMOTE. The following code shows an example of achieving the same thing by changing the properties.

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

That’s it!

2.5 Dependencies

The best way to add dependencies is to use the proper starter dependency.

For stub-runner, use spring-cloud-starter-stub-runner. When you use a plugin, add -spring-cloud-starter-contract-verifier.

2.6 Additional Links

Here are some resources related to Spring Cloud Contract Verifier and Stub Runner. Note + repositoryRoot: http://repo.spring.io/libs-snapshot

That’s it!

2.6 Dependencies

The best way to add dependencies is to use the proper starter dependency.

For stub-runner, use spring-cloud-starter-stub-runner. When you use a plugin, add +spring-cloud-starter-contract-verifier.

2.7 Additional Links

Here are some resources related to Spring Cloud Contract Verifier and Stub Runner. Note that some may be outdated, because the Spring Cloud Contract Verifier project is under -constant development.

2.6.1 Spring Cloud Contract video

You can check out the video from the Warsaw JUG about Spring Cloud Contract:

2.6.2 Readings

2.7 Samples

You can find some samples at +constant development.

2.7.1 Spring Cloud Contract video

You can check out the video from the Warsaw JUG about Spring Cloud Contract:

2.7.2 Readings

2.8 Samples

You can find some samples at samples.

3. Spring Cloud Contract FAQ

3.1 Why use Spring Cloud Contract Verifier and not X ?

For the time being Spring Cloud Contract is a JVM based tool. So it could be your first pick when you’re already creating software for the JVM. This project has a lot of really interesting features but especially quite a few of them definitely make Spring Cloud Contract Verifier stand out on the "market" of Consumer Driven Contract (CDC) tooling. Out of many the most interesting are:

  • Possibility to do CDC with messaging
  • Clear and easy to use, statically typed DSL
  • Possibility to copy paste your current JSON file to the contract and only edit its elements
  • Automatic generation of tests from the defined Contract
  • Stub Runner functionality - the stubs are automatically downloaded at runtime from Nexus / Artifactory
  • Spring Cloud integration - no discovery service is needed for integration tests
  • Spring Cloud Contract integrates with Pact out of the box and provides easy hooks to extend its functionality
  • Via Docker adds support for any language & framework used

3.2 I don’t want to write a contract in Groovy!

No problem. You can write a contract in YAML!

3.3 What is this value(consumer(), producer()) ?

One of the biggest challenges related to stubs is their reusability. Only if they can be vastly used, will they serve their purpose. @@ -903,7 +904,7 @@ one to one to the contents of the repo.

Example of a <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <java.version>1.8</java.version> <spring-cloud-contract.version>2.1.0.BUILD-SNAPSHOT</spring-cloud-contract.version> - <spring-cloud-dependencies.version>Finchley.BUILD-SNAPSHOT</spring-cloud-dependencies.version> + <spring-cloud-release.version>Finchley.BUILD-SNAPSHOT</spring-cloud-release.version> <excludeBuildFolders>true</excludeBuildFolders> </properties> @@ -912,7 +913,7 @@ one to one to the contents of the repo.

Example of a <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> - <version>${spring-cloud-dependencies.version}</version> + <version>${spring-cloud-release.version}</version> <type>pom</type> <scope>import</scope> </dependency> @@ -4987,7 +4988,20 @@ to work with Web Flux.

Maven.  // your tests go here // in this config class you define all controllers and mocked services - include::{samples_url}/producer_webflux/src/test/java/com/example/BeerRestBase.java[tags=config,indent=0] +@Configuration +@EnableAutoConfiguration +static class Config { + + @Bean + PersonCheckingService personCheckingService() { + return personToCheck -> personToCheck.age >= 20; + } + + @Bean + ProducerController producerController() { + return new ProducerController(personCheckingService()); + } +} }

8.10 Messaging Top-Level Elements

The DSL for messaging looks a little bit different than the one that focuses on HTTP. The following sections explain the differences:

8.10.1 Output Triggered by a Method

The output message can be triggered by calling a method (such as a Scheduler when a was @@ -5927,7 +5941,7 @@ to clone the repository and use it as a source of contracts to generate tests or stubs.

Either via environment variables, system properties, properties set inside the plugin or contracts repository configuration you can tweak the downloader’s behaviour. Below you can find the list of -properties

Table 10.1. SCM Stub Downloader properties

Type of a property

Name of the property

Description

* git.branch (plugin prop) +properties

Table 10.1. SCM Stub Downloader properties

Type of a property

Name of the property

Description

* git.branch (plugin prop)

* stubrunner.properties.git.branch (system prop)

* STUBRUNNER_PROPERTIES_GIT_BRANCH (env prop)

master

Which branch to checkout

* git.username (plugin prop)

* stubrunner.properties.git.username (system prop) @@ -5943,7 +5957,7 @@ to fetch the Pact contract definitions from the Pact Broker. Whatever is set after pact:// will be parsed as the Pact Broker URL.

Either via environment variables, system properties, properties set inside the plugin or contracts repository configuration you can tweak the downloader’s behaviour. Below you can find the list of -properties

Table 10.2. SCM Stub Downloader properties

Name of a property

Default

Description

* pactbroker.host (plugin prop) +properties

Table 10.2. SCM Stub Downloader properties

- + diff --git a/spring-cloud-contract.xml b/spring-cloud-contract.xml index 7b12823b4b..af86484290 100644 --- a/spring-cloud-contract.xml +++ b/spring-cloud-contract.xml @@ -22,10 +22,6 @@ that a contract is kept by producers and consumers. Spring Cloud Contract Verifier Introduction - -The Accurest project was initially started by Marcin Grzejszczak and Jakub Kubrynski -(codearte.io) - Spring Cloud Contract Verifier enables Consumer Driven Contract (CDC) development of JVM-based applications. It moves TDD to the level of software architecture. Spring Cloud Contract Verifier ships with Contract Definition Language (CDL). Contract @@ -47,6 +43,13 @@ of the API is compliant with the contract (server tests). A Spring Cloud Contract Verifier. +
+History +Before becoming Spring Cloud Contract, this project was called Accurest. +It was created by Marcin Grzejszczak and Jakub Kubrynski +from (codearte.io. +The 0.1.0 release took place on 26 Jan 2015 and it became stable with 1.0.0 release on 29 Feb 2016. +
Why a Contract Verifier? Assume that we have a system consisting of multiple microservices: @@ -1102,7 +1105,7 @@ Application service): <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> - <version>${spring-cloud-dependencies.version}</version> + <version>${spring-cloud-release-train.version}</version> <type>pom</type> <scope>import</scope> </dependency> @@ -1562,7 +1565,7 @@ one to one to the contents of the repo. <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <java.version>1.8</java.version> <spring-cloud-contract.version>2.1.0.BUILD-SNAPSHOT</spring-cloud-contract.version> - <spring-cloud-dependencies.version>Finchley.BUILD-SNAPSHOT</spring-cloud-dependencies.version> + <spring-cloud-release.version>Finchley.BUILD-SNAPSHOT</spring-cloud-release.version> <excludeBuildFolders>true</excludeBuildFolders> </properties> @@ -1571,7 +1574,7 @@ one to one to the contents of the repo. <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> - <version>${spring-cloud-dependencies.version}</version> + <version>${spring-cloud-release.version}</version> <type>pom</type> <scope>import</scope> </dependency> @@ -8121,7 +8124,20 @@ public abstract class BeerRestBase { // your tests go here // in this config class you define all controllers and mocked services - include::{samples_url}/producer_webflux/src/test/java/com/example/BeerRestBase.java[tags=config,indent=0] +@Configuration +@EnableAutoConfiguration +static class Config { + + @Bean + PersonCheckingService personCheckingService() { + return personToCheck -> personToCheck.age >= 20; + } + + @Bean + ProducerController producerController() { + return new ProducerController(personCheckingService()); + } +} }

Name of a property

Default

Description

* pactbroker.host (plugin prop)

* stubrunner.properties.pactbroker.host (system prop)

* STUBRUNNER_PROPERTIES_PACTBROKER_HOST (env prop)

Host from URL passed to repositoryRoot

What is the URL of Pact Broker

* pactbroker.port (plugin prop)

* stubrunner.properties.pactbroker.port (system prop) diff --git a/spring-cloud-contract-maven-plugin/plugin-management.html b/spring-cloud-contract-maven-plugin/plugin-management.html index 43d7e45b13..02209c4bdd 100644 --- a/spring-cloud-contract-maven-plugin/plugin-management.html +++ b/spring-cloud-contract-maven-plugin/plugin-management.html @@ -413,7 +413,7 @@

org.springframework.boot spring-boot-maven-plugin2.0.3.RELEASE
2.0.4.RELEASE
pl.project13.maven git-commit-id-plugin