diff --git a/1.2.x/multi/multi__contract_dsl.html b/1.2.x/multi/multi__contract_dsl.html index 17d6f7e67f..a339ff92a9 100644 --- a/1.2.x/multi/multi__contract_dsl.html +++ b/1.2.x/multi/multi__contract_dsl.html @@ -94,7 +94,7 @@ response: regex: bar - key: foo3 command: andMeToo($it)
[Tip]Tip

You can compile contracts to stubs mapping using standalone maven command: -mvn org.springframework.cloud:spring-cloud-contract-maven-plugin:convert

8.1 Limitations

[Warning]Warning

Spring Cloud Contract Verifier does not properly support XML. Please use JSON or +mvn org.springframework.cloud:spring-cloud-contract-maven-plugin:convert

8.1 Limitations

[Warning]Warning

Spring Cloud Contract Verifier does not properly support XML. Please use JSON or help us implement this feature.

[Warning]Warning

The support for verifying the size of JSON arrays is experimental. If you want to turn it on, please set the value of the following system property to true: spring.cloud.contract.verifier.assert.size. By default, this feature is set to false. diff --git a/1.2.x/multi/multi__spring_cloud_contract_stub_runner.html b/1.2.x/multi/multi__spring_cloud_contract_stub_runner.html index ff06176faf..b32aea86d8 100644 --- a/1.2.x/multi/multi__spring_cloud_contract_stub_runner.html +++ b/1.2.x/multi/multi__spring_cloud_contract_stub_runner.html @@ -220,11 +220,7 @@ structure in your stubs jar.

└──
                 │       └── contract2.groovy
                 └── mappings
                     └── mapping.json

By maintaining this structure classpath gets scanned and you can profit from the messaging / -HTTP stubs without the need to download artifacts.

6.3.2 Running stubs

Limitations

[Important]Important

There might be a problem with StubRunner shutting down ports between tests. You might - have a situation in which you get port conflicts. As long as you use the same context across tests - everything works fine. But when the context are different (e.g. different stubs or different profiles) - then you have to either use @DirtiesContext to shut down the stub servers, or else run them on - different ports per test.

Running using main app

You can set the following options to the main class:

-c, --classifier                Suffix for the jar containing stubs (e.
+HTTP stubs without the need to download artifacts.

6.3.2 Running stubs

Running using main app

You can set the following options to the main class:

-c, --classifier                Suffix for the jar containing stubs (e.
                                   g. 'stubs' if the stub jar would
                                   have a 'stubs' classifier for stubs:
                                   foobar-stubs ). Defaults to 'stubs'
@@ -384,7 +380,6 @@ its methods as presented below:

 @AutoConfigureStubRunner(mappingsOutputFolder = "target/outputmappings/")
-@DirtiesContext
 @ActiveProfiles("test")
 class StubRunnerConfigurationSpec extends Specification {
 
@@ -662,7 +657,6 @@ Or set the test as follows:
@AutoConfigureStubRunner(ids = "org.springframework.cloud.contract.verifier.stubs:producerWithMultipleConsumers",
 		repositoryRoot = "classpath:m2repo/repository/",
 		stubsPerConsumer = true)
-@DirtiesContext
 class StubRunnerStubsPerConsumerSpec extends Specification {
 ...
 }
Then only the stubs registered under a path that contains the bar-consumer in its name (i.e. those from the
@@ -672,7 +666,6 @@ Or set the test as follows:

-@DirtiesContext
 class StubRunnerStubsPerConsumerWithConsumerNameSpec extends Specification {
 ...
 }
Then only the stubs registered under a path that contains the foo-consumer in its name (i.e. those from the
diff --git a/1.2.x/multi/multi__spring_cloud_contract_verifier_introduction.html b/1.2.x/multi/multi__spring_cloud_contract_verifier_introduction.html
index 871cb10cd3..e97d138b60 100644
--- a/1.2.x/multi/multi__spring_cloud_contract_verifier_introduction.html
+++ b/1.2.x/multi/multi__spring_cloud_contract_verifier_introduction.html
@@ -146,7 +146,6 @@ You would like to feed that instance with a proper stub definition.
At som
 				FraudServiceResponse.class);
Annotate your test class with @AutoConfigureStubRunner. In the annotation provide the group id and artifact id for the Stub Runner to download stubs of your collaborators.
@RunWith(SpringRunner.class)
 @SpringBootTest(webEnvironment=WebEnvironment.NONE)
 @AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:6565"}, workOffline = true)
-@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.3 Server Side

Since you are developing your stub, you need to be sure that it actually resembles your @@ -443,7 +442,6 @@ collaborators. (Optional step) Because you’re playing with the collaborato can also provide the offline work switch.

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

Now, when you run your tests, you see something like this:

2016-07-19 14:22:25.403  INFO 41050 --- [           main] o.s.c.c.stubrunner.AetherStubDownloader  : Desired version is + - will try to resolve the latest version
 2016-07-19 14:22:25.438  INFO 41050 --- [           main] o.s.c.c.stubrunner.AetherStubDownloader  : Resolved version is 0.0.1-SNAPSHOT
 2016-07-19 14:22:25.439  INFO 41050 --- [           main] o.s.c.c.stubrunner.AetherStubDownloader  : Resolving artifact com.example:http-server:jar:stubs:0.0.1-SNAPSHOT using remote repositories []
diff --git a/1.2.x/multi/multi_spring-cloud-contract.html b/1.2.x/multi/multi_spring-cloud-contract.html
index 94bff9a593..ce7b49d6d4 100644
--- a/1.2.x/multi/multi_spring-cloud-contract.html
+++ b/1.2.x/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. Defining the contract
2.3.2. Client Side
2.3.3. 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.6. Can I have multiple base classes for tests?
3.7. How can I debug the request/response being sent by the generated tests client?
3.7.1. How can I debug the mapping/request/response being sent by WireMock?
3.7.2. How can I see what got registered in the HTTP server stub?
3.7.3. Can I reference the request from the response?
3.7.4. 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. 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. 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 Camel
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 Integration
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 Stream
7.4.1. Adding the Runner to the Project
7.4.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.5. Stub Runner Spring AMQP
7.5.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. Messaging Top-Level Elements
8.9.1. Output Triggered by a Method
8.9.2. Output Triggered by a Message
8.9.3. Consumer/Producer
8.9.4. Common
8.10. Multiple Contracts in One File
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
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
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. Why a Contract Verifier?
2.1.1. Testing issues
2.2. Purposes
2.3. How It Works
2.3.1. Defining the contract
2.3.2. Client Side
2.3.3. 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.6. Can I have multiple base classes for tests?
3.7. How can I debug the request/response being sent by the generated tests client?
3.7.1. How can I debug the mapping/request/response being sent by WireMock?
3.7.2. How can I see what got registered in the HTTP server stub?
3.7.3. Can I reference the request from the response?
3.7.4. 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. 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. 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
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 Camel
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 Integration
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 Stream
7.4.1. Adding the Runner to the Project
7.4.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.5. Stub Runner Spring AMQP
7.5.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. Messaging Top-Level Elements
8.9.1. Output Triggered by a Method
8.9.2. Output Triggered by a Message
8.9.3. Consumer/Producer
8.9.4. Common
8.10. Multiple Contracts in One File
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
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
13. Links
   Next
   

\ No newline at end of file
diff --git a/1.2.x/single/spring-cloud-contract.html b/1.2.x/single/spring-cloud-contract.html
index a4bc7f32e3..c4642131e8 100644
--- a/1.2.x/single/spring-cloud-contract.html
+++ b/1.2.x/single/spring-cloud-contract.html
@@ -1,6 +1,6 @@
 
       
-   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. Defining the contract
2.3.2. Client Side
2.3.3. 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.6. Can I have multiple base classes for tests?
3.7. How can I debug the request/response being sent by the generated tests client?
3.7.1. How can I debug the mapping/request/response being sent by WireMock?
3.7.2. How can I see what got registered in the HTTP server stub?
3.7.3. Can I reference the request from the response?
3.7.4. 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. 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. 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 Camel
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 Integration
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 Stream
7.4.1. Adding the Runner to the Project
7.4.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.5. Stub Runner Spring AMQP
7.5.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. Messaging Top-Level Elements
8.9.1. Output Triggered by a Method
8.9.2. Output Triggered by a Message
8.9.3. Consumer/Producer
8.9.4. Common
8.10. Multiple Contracts in One File
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
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
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. Why a Contract Verifier?
2.1.1. Testing issues
2.2. Purposes
2.3. How It Works
2.3.1. Defining the contract
2.3.2. Client Side
2.3.3. 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.6. Can I have multiple base classes for tests?
3.7. How can I debug the request/response being sent by the generated tests client?
3.7.1. How can I debug the mapping/request/response being sent by WireMock?
3.7.2. How can I see what got registered in the HTTP server stub?
3.7.3. Can I reference the request from the response?
3.7.4. 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. 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. 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
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 Camel
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 Integration
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 Stream
7.4.1. Adding the Runner to the Project
7.4.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.5. Stub Runner Spring AMQP
7.5.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. Messaging Top-Level Elements
8.9.1. Output Triggered by a Method
8.9.2. Output Triggered by a Message
8.9.3. Consumer/Producer
8.9.4. Common
8.10. Multiple Contracts in One File
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
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
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
1.2.6.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),
@@ -151,7 +151,6 @@ You would like to feed that instance with a proper stub definition.
At som
 				FraudServiceResponse.class);

Annotate your test class with @AutoConfigureStubRunner. In the annotation provide the group id and artifact id for the Stub Runner to download stubs of your collaborators.

@RunWith(SpringRunner.class)
 @SpringBootTest(webEnvironment=WebEnvironment.NONE)
 @AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:6565"}, workOffline = true)
-@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.3 Server Side

Since you are developing your stub, you need to be sure that it actually resembles your @@ -448,7 +447,6 @@ collaborators. (Optional step) Because you’re playing with the collaborato can also provide the offline work switch.

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

Now, when you run your tests, you see something like this:

2016-07-19 14:22:25.403  INFO 41050 --- [           main] o.s.c.c.stubrunner.AetherStubDownloader  : Desired version is + - will try to resolve the latest version
 2016-07-19 14:22:25.438  INFO 41050 --- [           main] o.s.c.c.stubrunner.AetherStubDownloader  : Resolved version is 0.0.1-SNAPSHOT
 2016-07-19 14:22:25.439  INFO 41050 --- [           main] o.s.c.c.stubrunner.AetherStubDownloader  : Resolving artifact com.example:http-server:jar:stubs:0.0.1-SNAPSHOT using remote repositories []
@@ -1944,11 +1942,7 @@ structure in your stubs jar.
└──
                 │       └── contract2.groovy
                 └── mappings
                     └── mapping.json
By maintaining this structure classpath gets scanned and you can profit from the messaging /
-HTTP stubs without the need to download artifacts.

6.3.2 Running stubs

Limitations

[Important]Important

There might be a problem with StubRunner shutting down ports between tests. You might - have a situation in which you get port conflicts. As long as you use the same context across tests - everything works fine. But when the context are different (e.g. different stubs or different profiles) - then you have to either use @DirtiesContext to shut down the stub servers, or else run them on - different ports per test.

Running using main app

You can set the following options to the main class:

-c, --classifier                Suffix for the jar containing stubs (e.
+HTTP stubs without the need to download artifacts.

6.3.2 Running stubs

Running using main app

You can set the following options to the main class:

-c, --classifier                Suffix for the jar containing stubs (e.
                                   g. 'stubs' if the stub jar would
                                   have a 'stubs' classifier for stubs:
                                   foobar-stubs ). Defaults to 'stubs'
@@ -2108,7 +2102,6 @@ its methods as presented below:

 @AutoConfigureStubRunner(mappingsOutputFolder = "target/outputmappings/")
-@DirtiesContext
 @ActiveProfiles("test")
 class StubRunnerConfigurationSpec extends Specification {
 
@@ -2386,7 +2379,6 @@ Or set the test as follows:
@AutoConfigureStubRunner(ids = "org.springframework.cloud.contract.verifier.stubs:producerWithMultipleConsumers",
 		repositoryRoot = "classpath:m2repo/repository/",
 		stubsPerConsumer = true)
-@DirtiesContext
 class StubRunnerStubsPerConsumerSpec extends Specification {
 ...
 }
Then only the stubs registered under a path that contains the bar-consumer in its name (i.e. those from the
@@ -2396,7 +2388,6 @@ Or set the test as follows:

-@DirtiesContext
 class StubRunnerStubsPerConsumerWithConsumerNameSpec extends Specification {
 ...
 }
Then only the stubs registered under a path that contains the foo-consumer in its name (i.e. those from the
@@ -2883,7 +2874,7 @@ response:
         regex: bar
       - key: foo3
         command: andMeToo($it)
[Tip]Tip
You can compile contracts to stubs mapping using standalone maven command:
-mvn org.springframework.cloud:spring-cloud-contract-maven-plugin:convert
8.1 Limitations
[Warning]Warning
Spring Cloud Contract Verifier does not properly support XML. Please use JSON or
+mvn org.springframework.cloud:spring-cloud-contract-maven-plugin:convert
8.1 Limitations
[Warning]Warning
Spring Cloud Contract Verifier does not properly support XML. Please use JSON or
 help us implement this feature.
[Warning]Warning
The support for verifying the size of JSON arrays is experimental. If you want
 to turn it on, please set the value of the following system property to true:
 spring.cloud.contract.verifier.assert.size. By default, this feature is set to false.
diff --git a/1.2.x/spring-cloud-contract.xml b/1.2.x/spring-cloud-contract.xml
index 078a8ec136..b572c392f8 100644
--- a/1.2.x/spring-cloud-contract.xml
+++ b/1.2.x/spring-cloud-contract.xml
@@ -309,7 +309,6 @@ You would like to feed that instance with a proper stub definition.
 @RunWith(SpringRunner.class)
 @SpringBootTest(webEnvironment=WebEnvironment.NONE)
 @AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:6565"}, workOffline = true)
-@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
@@ -768,7 +767,6 @@ can also provide the offline work switch.
 @RunWith(SpringRunner.class)
 @SpringBootTest(webEnvironment=WebEnvironment.NONE)
 @AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:6565"}, workOffline = true)
-@DirtiesContext
 public class LoanApplicationServiceTests {
 Now, when you run your tests, you see something like this:
 2016-07-19 14:22:25.403  INFO 41050 --- [           main] o.s.c.c.stubrunner.AetherStubDownloader  : Desired version is + - will try to resolve the latest version
@@ -3347,16 +3345,6 @@ HTTP stubs without the need to download artifacts.
 
 

 Running stubs
-

-Limitations
-
-There might be a problem with StubRunner shutting down ports between tests. You might
- have a situation in which you get port conflicts. As long as you use the same context across tests
- everything works fine. But when the context are different (e.g. different stubs or different profiles)
- then you have to either use @DirtiesContext to shut down the stub servers, or else run them on
- different ports per test.
-
-

 

 Running using main app
 You can set the following options to the main class:
@@ -3602,7 +3590,6 @@ its methods as presented below:
 		"stubrunner.camel.enabled=false",
 		'foo=${stubrunner.runningstubs.fraudDetectionServer.port}'])
 @AutoConfigureStubRunner(mappingsOutputFolder = "target/outputmappings/")
-@DirtiesContext
 @ActiveProfiles("test")
 class StubRunnerConfigurationSpec extends Specification {
 
@@ -4041,7 +4028,6 @@ Or set the test as follows:
 @AutoConfigureStubRunner(ids = "org.springframework.cloud.contract.verifier.stubs:producerWithMultipleConsumers",
 		repositoryRoot = "classpath:m2repo/repository/",
 		stubsPerConsumer = true)
-@DirtiesContext
 class StubRunnerStubsPerConsumerSpec extends Specification {
 ...
 }
@@ -4054,7 +4040,6 @@ class StubRunnerStubsPerConsumerSpec extends Specification {
 		repositoryRoot = "classpath:m2repo/repository/",
 		consumerName = "foo-consumer",
 		stubsPerConsumer = true)
-@DirtiesContext
 class StubRunnerStubsPerConsumerWithConsumerNameSpec extends Specification {
 ...
 }
@@ -4986,7 +4971,7 @@ response:
 You can compile contracts to stubs mapping using standalone maven command:
 mvn org.springframework.cloud:spring-cloud-contract-maven-plugin:convert
 
-

+

 Limitations
 
 Spring Cloud Contract Verifier does not properly support XML. Please use JSON or