diff --git a/2.0.x/multi/multi__contract_dsl.html b/2.0.x/multi/multi__contract_dsl.html index 2d79cedf18..ff72d82df6 100644 --- a/2.0.x/multi/multi__contract_dsl.html +++ b/2.0.x/multi/multi__contract_dsl.html @@ -280,7 +280,7 @@ such as named("fileName", "fileContent"), or via a }, "response" : { "status" : 200, - "transformers" : [ "response-template" ] + "transformers" : [ "response-template", "foo-transformer" ] } } '''

7.4 Response

The response must contain an HTTP status code and may contain other information. The @@ -691,7 +691,16 @@ in sending the following response body:

}
[Important]Important

This feature works only with WireMock having a version greater than or equal to 2.5.1. The Spring Cloud Contract Verifier uses WireMock’s response-template response transformer. It uses Handlebars to convert the Mustache {{{ }}} templates into -proper values. Additionally, it registers two helper functions:

7.5.6 Dynamic Properties in the Matchers Sections

If you work with Pact, the following discussion may seem familiar. +proper values. Additionally, it registers two helper functions:

7.5.6 Registering Your Own WireMock Extension

WireMock lets you register custom extensions. By default, Spring Cloud Contract registers +the transformer, which lets you reference a request from a response. If you want to +provide your own extensions, you can register an implementation of the +org.springframework.cloud.contract.verifier.dsl.wiremock.WireMockExtensions interface. +Since we use the spring.factories extension approach, you can create an entry in +META-INF/spring.factories file similar to the following:

org.springframework.cloud.contract.verifier.dsl.wiremock.WireMockExtensions=\
+org.springframework.cloud.contract.stubrunner.provider.wiremock.TestWireMockExtensions

The following is an example of a custom extension:

TestWireMockExtensions.groovy.  +

Unresolved directive in verifier_contract.adoc - include::../../../../spring-cloud-contract-stub-runner/src/test/groovy/org/springframework/cloud/contract/verifier/dsl/wiremock/TestWireMockExtensions.groovy[indent=0]

+

[Important]Important

Remember to override the applyGlobally() method and set it to false if you +want the transformation to be applied only for a mapping that explicitly requires it.

7.5.7 Dynamic Properties in the Matchers Sections

If you work with Pact, the following discussion may seem familiar. Quite a few users are used to having a separation between the body and setting the dynamic parts of a contract.

You can use two separate sections:

The following example shows a typical spring.factories file:

# Converters
 org.springframework.cloud.contract.spec.ContractConverter=\
-org.springframework.cloud.contract.verifier.converter.YamlContractConverter

The following example shows a typical YAML implementation that matches the preceding +org.springframework.cloud.contract.verifier.converter.YamlContractConverter + +# tag::extension[] +org.springframework.cloud.contract.verifier.dsl.wiremock.WireMockExtensions=\ +org.springframework.cloud.contract.verifier.dsl.wiremock.TestWireMockExtensions +# end::extension[]

The following example shows a typical YAML implementation that matches the preceding example:

package org.springframework.cloud.contract.verifier.converter
 
 import java.nio.file.Files
diff --git a/2.0.x/multi/multi_spring-cloud-contract.html b/2.0.x/multi/multi_spring-cloud-contract.html
index 4ecb2b7481..914b418f22 100644
--- a/2.0.x/multi/multi_spring-cloud-contract.html
+++ b/2.0.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 Verifier Setup
3.1. Gradle Project
3.1.1. Prerequisites
3.1.2. Add Gradle Plugin with Dependencies
3.1.3. Gradle and Rest Assured 2.0
3.1.4. Snapshot Versions for Gradle
3.1.5. Add stubs
3.1.6. Run the Plugin
3.1.7. Default Setup
3.1.8. Configure Plugin
3.1.9. Configuration Options
3.1.10. Single Base Class for All Tests
3.1.11. Different Base Classes for Contracts
3.1.12. Invoking Generated Tests
3.1.13. Spring Cloud Contract Verifier on the Consumer Side
3.2. Maven Project
3.2.1. Add maven plugin
3.2.2. Maven and Rest Assured 2.0
3.2.3. Snapshot versions for Maven
3.2.4. Add stubs
3.2.5. Run plugin
3.2.6. Configure plugin
3.2.7. Configuration Options
3.2.8. Single Base Class for All Tests
3.2.9. Different base classes for contracts
3.2.10. Invoking generated tests
3.2.11. Maven Plugin and STS
3.2.12. Spring Cloud Contract Verifier on the Consumer Side
3.3. Stubs and Transitive Dependencies
3.4. Scenarios
4. Spring Cloud Contract Verifier Messaging
4.1. Integrations
4.2. Manual Integration Testing
4.3. Publisher-Side Test Generation
4.3.1. Scenario 1: No Input Message
4.3.2. Scenario 2: Output Triggered by Input
4.3.3. Scenario 3: No Output Message
4.4. Consumer Stub Generation
5. Spring Cloud Contract Stub Runner
5.1. Snapshot versions
5.2. Publishing Stubs as JARs
5.3. Stub Runner Core
5.3.1. Retrieving stubs
Stub downloading
Classpath scanning
5.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
5.4. Stub Runner JUnit Rule
5.4.1. Maven settings
5.4.2. Providing fixed ports
5.4.3. Fluent API
5.4.4. Stub Runner with Spring
5.5. Stub Runner Spring Cloud
5.5.1. Stubbing Service Discovery
Test profiles and service discovery
5.5.2. Additional Configuration
5.6. Stub Runner Boot Application
5.6.1. How to use it?
Stub Runner Server
Spring Cloud CLI
5.6.2. Endpoints
HTTP
Messaging
5.6.3. Example
5.6.4. Stub Runner Boot with Service Discovery
5.7. Stubs Per Consumer
5.8. Common
5.8.1. Common Properties for JUnit and Spring
5.8.2. Stub Runner Stubs IDs
6. Stub Runner for Messaging
6.1. Stub triggering
6.1.1. Trigger by Label
6.1.2. Trigger by Group and Artifact Ids
6.1.3. Trigger by Artifact Ids
6.1.4. Trigger All Messages
6.2. Stub Runner Integration
6.2.1. Adding the Runner to the Project
6.2.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.3. Stub Runner Stream
6.3.1. Adding the Runner to the Project
6.3.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.4. Stub Runner Spring AMQP
6.4.1. Adding the Runner to the Project
Triggering the message
Spring AMQP Test Configuration
7. Contract DSL
7.1. Limitations
7.2. Common Top-Level elements
7.2.1. Description
7.2.2. Name
7.2.3. Ignoring Contracts
7.2.4. Passing Values from Files
7.2.5. HTTP Top-Level Elements
7.3. Request
7.4. Response
7.5. Dynamic properties
7.5.1. Dynamic properties inside the body
7.5.2. Regular expressions
7.5.3. Passing Optional Parameters
7.5.4. Executing Custom Methods on the Server Side
7.5.5. Referencing the Request from the Response
7.5.6. Dynamic Properties in the Matchers Sections
7.6. JAX-RS Support
7.7. Async Support
7.8. Working with Context Paths
7.9. Messaging Top-Level Elements
7.9.1. Output Triggered by a Method
7.9.2. Output Triggered by a Message
7.9.3. Consumer/Producer
7.10. Multiple Contracts in One File
8. Customization
8.1. Extending the DSL
8.1.1. Common JAR
8.1.2. Adding the Dependency to the Project
8.1.3. Test the Dependency in the Project’s Dependencies
8.1.4. Test a Dependency in the Plugin’s Dependencies
8.1.5. Referencing classes in DSLs
9. Using the Pluggable Architecture
9.1. Custom Contract Converter
9.1.1. Pact Converter
9.1.2. Pact Contract
9.1.3. Pact for Producers
9.1.4. Pact for Consumers
9.2. Using the Custom Test Generator
9.3. Using the Custom Stub Generator
9.4. Using the Custom Stub Runner
9.5. Using the Custom Stub Downloader
10. Spring Cloud Contract WireMock
10.1. Registering Stubs Automatically
10.2. Using Files to Specify the Stub Bodies
10.3. Alternative: Using JUnit Rules
10.4. Relaxed SSL Validation for Rest Template
10.5. WireMock and Spring MVC Mocks
10.6. Generating Stubs using REST Docs
10.7. Generating Contracts by Using REST Docs
11. Migrations
11.1. 1.0.x → 1.1.x
11.1.1. New structure of generated stubs
11.2. 1.1.x → 1.2.x
11.2.1. Custom HttpServerStub
11.2.2. New packages for generated tests
11.2.3. New Methods in TemplateProcessor
11.2.4. RestAssured 3.0
11.3. 1.2.x → 2.0.x
11.3.1. No Camel support
12. 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 Verifier Setup
3.1. Gradle Project
3.1.1. Prerequisites
3.1.2. Add Gradle Plugin with Dependencies
3.1.3. Gradle and Rest Assured 2.0
3.1.4. Snapshot Versions for Gradle
3.1.5. Add stubs
3.1.6. Run the Plugin
3.1.7. Default Setup
3.1.8. Configure Plugin
3.1.9. Configuration Options
3.1.10. Single Base Class for All Tests
3.1.11. Different Base Classes for Contracts
3.1.12. Invoking Generated Tests
3.1.13. Spring Cloud Contract Verifier on the Consumer Side
3.2. Maven Project
3.2.1. Add maven plugin
3.2.2. Maven and Rest Assured 2.0
3.2.3. Snapshot versions for Maven
3.2.4. Add stubs
3.2.5. Run plugin
3.2.6. Configure plugin
3.2.7. Configuration Options
3.2.8. Single Base Class for All Tests
3.2.9. Different base classes for contracts
3.2.10. Invoking generated tests
3.2.11. Maven Plugin and STS
3.2.12. Spring Cloud Contract Verifier on the Consumer Side
3.3. Stubs and Transitive Dependencies
3.4. Scenarios
4. Spring Cloud Contract Verifier Messaging
4.1. Integrations
4.2. Manual Integration Testing
4.3. Publisher-Side Test Generation
4.3.1. Scenario 1: No Input Message
4.3.2. Scenario 2: Output Triggered by Input
4.3.3. Scenario 3: No Output Message
4.4. Consumer Stub Generation
5. Spring Cloud Contract Stub Runner
5.1. Snapshot versions
5.2. Publishing Stubs as JARs
5.3. Stub Runner Core
5.3.1. Retrieving stubs
Stub downloading
Classpath scanning
5.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
5.4. Stub Runner JUnit Rule
5.4.1. Maven settings
5.4.2. Providing fixed ports
5.4.3. Fluent API
5.4.4. Stub Runner with Spring
5.5. Stub Runner Spring Cloud
5.5.1. Stubbing Service Discovery
Test profiles and service discovery
5.5.2. Additional Configuration
5.6. Stub Runner Boot Application
5.6.1. How to use it?
Stub Runner Server
Spring Cloud CLI
5.6.2. Endpoints
HTTP
Messaging
5.6.3. Example
5.6.4. Stub Runner Boot with Service Discovery
5.7. Stubs Per Consumer
5.8. Common
5.8.1. Common Properties for JUnit and Spring
5.8.2. Stub Runner Stubs IDs
6. Stub Runner for Messaging
6.1. Stub triggering
6.1.1. Trigger by Label
6.1.2. Trigger by Group and Artifact Ids
6.1.3. Trigger by Artifact Ids
6.1.4. Trigger All Messages
6.2. Stub Runner Integration
6.2.1. Adding the Runner to the Project
6.2.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.3. Stub Runner Stream
6.3.1. Adding the Runner to the Project
6.3.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.4. Stub Runner Spring AMQP
6.4.1. Adding the Runner to the Project
Triggering the message
Spring AMQP Test Configuration
7. Contract DSL
7.1. Limitations
7.2. Common Top-Level elements
7.2.1. Description
7.2.2. Name
7.2.3. Ignoring Contracts
7.2.4. Passing Values from Files
7.2.5. HTTP Top-Level Elements
7.3. Request
7.4. Response
7.5. Dynamic properties
7.5.1. Dynamic properties inside the body
7.5.2. Regular expressions
7.5.3. Passing Optional Parameters
7.5.4. Executing Custom Methods on the Server Side
7.5.5. Referencing the Request from the Response
7.5.6. Registering Your Own WireMock Extension
7.5.7. Dynamic Properties in the Matchers Sections
7.6. JAX-RS Support
7.7. Async Support
7.8. Working with Context Paths
7.9. Messaging Top-Level Elements
7.9.1. Output Triggered by a Method
7.9.2. Output Triggered by a Message
7.9.3. Consumer/Producer
7.10. Multiple Contracts in One File
8. Customization
8.1. Extending the DSL
8.1.1. Common JAR
8.1.2. Adding the Dependency to the Project
8.1.3. Test the Dependency in the Project’s Dependencies
8.1.4. Test a Dependency in the Plugin’s Dependencies
8.1.5. Referencing classes in DSLs
9. Using the Pluggable Architecture
9.1. Custom Contract Converter
9.1.1. Pact Converter
9.1.2. Pact Contract
9.1.3. Pact for Producers
9.1.4. Pact for Consumers
9.2. Using the Custom Test Generator
9.3. Using the Custom Stub Generator
9.4. Using the Custom Stub Runner
9.5. Using the Custom Stub Downloader
10. Spring Cloud Contract WireMock
10.1. Registering Stubs Automatically
10.2. Using Files to Specify the Stub Bodies
10.3. Alternative: Using JUnit Rules
10.4. Relaxed SSL Validation for Rest Template
10.5. WireMock and Spring MVC Mocks
10.6. Generating Stubs using REST Docs
10.7. Generating Contracts by Using REST Docs
11. Migrations
11.1. 1.0.x → 1.1.x
11.1.1. New structure of generated stubs
11.2. 1.1.x → 1.2.x
11.2.1. Custom HttpServerStub
11.2.2. New packages for generated tests
11.2.3. New Methods in TemplateProcessor
11.2.4. RestAssured 3.0
11.3. 1.2.x → 2.0.x
11.3.1. No Camel support
12. Links
   Next
   

\ No newline at end of file
diff --git a/2.0.x/single/spring-cloud-contract.html b/2.0.x/single/spring-cloud-contract.html
index 30c8c70f38..865cee6465 100644
--- a/2.0.x/single/spring-cloud-contract.html
+++ b/2.0.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 Verifier Setup
3.1. Gradle Project
3.1.1. Prerequisites
3.1.2. Add Gradle Plugin with Dependencies
3.1.3. Gradle and Rest Assured 2.0
3.1.4. Snapshot Versions for Gradle
3.1.5. Add stubs
3.1.6. Run the Plugin
3.1.7. Default Setup
3.1.8. Configure Plugin
3.1.9. Configuration Options
3.1.10. Single Base Class for All Tests
3.1.11. Different Base Classes for Contracts
3.1.12. Invoking Generated Tests
3.1.13. Spring Cloud Contract Verifier on the Consumer Side
3.2. Maven Project
3.2.1. Add maven plugin
3.2.2. Maven and Rest Assured 2.0
3.2.3. Snapshot versions for Maven
3.2.4. Add stubs
3.2.5. Run plugin
3.2.6. Configure plugin
3.2.7. Configuration Options
3.2.8. Single Base Class for All Tests
3.2.9. Different base classes for contracts
3.2.10. Invoking generated tests
3.2.11. Maven Plugin and STS
3.2.12. Spring Cloud Contract Verifier on the Consumer Side
3.3. Stubs and Transitive Dependencies
3.4. Scenarios
4. Spring Cloud Contract Verifier Messaging
4.1. Integrations
4.2. Manual Integration Testing
4.3. Publisher-Side Test Generation
4.3.1. Scenario 1: No Input Message
4.3.2. Scenario 2: Output Triggered by Input
4.3.3. Scenario 3: No Output Message
4.4. Consumer Stub Generation
5. Spring Cloud Contract Stub Runner
5.1. Snapshot versions
5.2. Publishing Stubs as JARs
5.3. Stub Runner Core
5.3.1. Retrieving stubs
Stub downloading
Classpath scanning
5.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
5.4. Stub Runner JUnit Rule
5.4.1. Maven settings
5.4.2. Providing fixed ports
5.4.3. Fluent API
5.4.4. Stub Runner with Spring
5.5. Stub Runner Spring Cloud
5.5.1. Stubbing Service Discovery
Test profiles and service discovery
5.5.2. Additional Configuration
5.6. Stub Runner Boot Application
5.6.1. How to use it?
Stub Runner Server
Spring Cloud CLI
5.6.2. Endpoints
HTTP
Messaging
5.6.3. Example
5.6.4. Stub Runner Boot with Service Discovery
5.7. Stubs Per Consumer
5.8. Common
5.8.1. Common Properties for JUnit and Spring
5.8.2. Stub Runner Stubs IDs
6. Stub Runner for Messaging
6.1. Stub triggering
6.1.1. Trigger by Label
6.1.2. Trigger by Group and Artifact Ids
6.1.3. Trigger by Artifact Ids
6.1.4. Trigger All Messages
6.2. Stub Runner Integration
6.2.1. Adding the Runner to the Project
6.2.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.3. Stub Runner Stream
6.3.1. Adding the Runner to the Project
6.3.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.4. Stub Runner Spring AMQP
6.4.1. Adding the Runner to the Project
Triggering the message
Spring AMQP Test Configuration
7. Contract DSL
7.1. Limitations
7.2. Common Top-Level elements
7.2.1. Description
7.2.2. Name
7.2.3. Ignoring Contracts
7.2.4. Passing Values from Files
7.2.5. HTTP Top-Level Elements
7.3. Request
7.4. Response
7.5. Dynamic properties
7.5.1. Dynamic properties inside the body
7.5.2. Regular expressions
7.5.3. Passing Optional Parameters
7.5.4. Executing Custom Methods on the Server Side
7.5.5. Referencing the Request from the Response
7.5.6. Dynamic Properties in the Matchers Sections
7.6. JAX-RS Support
7.7. Async Support
7.8. Working with Context Paths
7.9. Messaging Top-Level Elements
7.9.1. Output Triggered by a Method
7.9.2. Output Triggered by a Message
7.9.3. Consumer/Producer
7.10. Multiple Contracts in One File
8. Customization
8.1. Extending the DSL
8.1.1. Common JAR
8.1.2. Adding the Dependency to the Project
8.1.3. Test the Dependency in the Project’s Dependencies
8.1.4. Test a Dependency in the Plugin’s Dependencies
8.1.5. Referencing classes in DSLs
9. Using the Pluggable Architecture
9.1. Custom Contract Converter
9.1.1. Pact Converter
9.1.2. Pact Contract
9.1.3. Pact for Producers
9.1.4. Pact for Consumers
9.2. Using the Custom Test Generator
9.3. Using the Custom Stub Generator
9.4. Using the Custom Stub Runner
9.5. Using the Custom Stub Downloader
10. Spring Cloud Contract WireMock
10.1. Registering Stubs Automatically
10.2. Using Files to Specify the Stub Bodies
10.3. Alternative: Using JUnit Rules
10.4. Relaxed SSL Validation for Rest Template
10.5. WireMock and Spring MVC Mocks
10.6. Generating Stubs using REST Docs
10.7. Generating Contracts by Using REST Docs
11. Migrations
11.1. 1.0.x → 1.1.x
11.1.1. New structure of generated stubs
11.2. 1.1.x → 1.2.x
11.2.1. Custom HttpServerStub
11.2.2. New packages for generated tests
11.2.3. New Methods in TemplateProcessor
11.2.4. RestAssured 3.0
11.3. 1.2.x → 2.0.x
11.3.1. No Camel support
12. 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 Verifier Setup
3.1. Gradle Project
3.1.1. Prerequisites
3.1.2. Add Gradle Plugin with Dependencies
3.1.3. Gradle and Rest Assured 2.0
3.1.4. Snapshot Versions for Gradle
3.1.5. Add stubs
3.1.6. Run the Plugin
3.1.7. Default Setup
3.1.8. Configure Plugin
3.1.9. Configuration Options
3.1.10. Single Base Class for All Tests
3.1.11. Different Base Classes for Contracts
3.1.12. Invoking Generated Tests
3.1.13. Spring Cloud Contract Verifier on the Consumer Side
3.2. Maven Project
3.2.1. Add maven plugin
3.2.2. Maven and Rest Assured 2.0
3.2.3. Snapshot versions for Maven
3.2.4. Add stubs
3.2.5. Run plugin
3.2.6. Configure plugin
3.2.7. Configuration Options
3.2.8. Single Base Class for All Tests
3.2.9. Different base classes for contracts
3.2.10. Invoking generated tests
3.2.11. Maven Plugin and STS
3.2.12. Spring Cloud Contract Verifier on the Consumer Side
3.3. Stubs and Transitive Dependencies
3.4. Scenarios
4. Spring Cloud Contract Verifier Messaging
4.1. Integrations
4.2. Manual Integration Testing
4.3. Publisher-Side Test Generation
4.3.1. Scenario 1: No Input Message
4.3.2. Scenario 2: Output Triggered by Input
4.3.3. Scenario 3: No Output Message
4.4. Consumer Stub Generation
5. Spring Cloud Contract Stub Runner
5.1. Snapshot versions
5.2. Publishing Stubs as JARs
5.3. Stub Runner Core
5.3.1. Retrieving stubs
Stub downloading
Classpath scanning
5.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
5.4. Stub Runner JUnit Rule
5.4.1. Maven settings
5.4.2. Providing fixed ports
5.4.3. Fluent API
5.4.4. Stub Runner with Spring
5.5. Stub Runner Spring Cloud
5.5.1. Stubbing Service Discovery
Test profiles and service discovery
5.5.2. Additional Configuration
5.6. Stub Runner Boot Application
5.6.1. How to use it?
Stub Runner Server
Spring Cloud CLI
5.6.2. Endpoints
HTTP
Messaging
5.6.3. Example
5.6.4. Stub Runner Boot with Service Discovery
5.7. Stubs Per Consumer
5.8. Common
5.8.1. Common Properties for JUnit and Spring
5.8.2. Stub Runner Stubs IDs
6. Stub Runner for Messaging
6.1. Stub triggering
6.1.1. Trigger by Label
6.1.2. Trigger by Group and Artifact Ids
6.1.3. Trigger by Artifact Ids
6.1.4. Trigger All Messages
6.2. Stub Runner Integration
6.2.1. Adding the Runner to the Project
6.2.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.3. Stub Runner Stream
6.3.1. Adding the Runner to the Project
6.3.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.4. Stub Runner Spring AMQP
6.4.1. Adding the Runner to the Project
Triggering the message
Spring AMQP Test Configuration
7. Contract DSL
7.1. Limitations
7.2. Common Top-Level elements
7.2.1. Description
7.2.2. Name
7.2.3. Ignoring Contracts
7.2.4. Passing Values from Files
7.2.5. HTTP Top-Level Elements
7.3. Request
7.4. Response
7.5. Dynamic properties
7.5.1. Dynamic properties inside the body
7.5.2. Regular expressions
7.5.3. Passing Optional Parameters
7.5.4. Executing Custom Methods on the Server Side
7.5.5. Referencing the Request from the Response
7.5.6. Registering Your Own WireMock Extension
7.5.7. Dynamic Properties in the Matchers Sections
7.6. JAX-RS Support
7.7. Async Support
7.8. Working with Context Paths
7.9. Messaging Top-Level Elements
7.9.1. Output Triggered by a Method
7.9.2. Output Triggered by a Message
7.9.3. Consumer/Producer
7.10. Multiple Contracts in One File
8. Customization
8.1. Extending the DSL
8.1.1. Common JAR
8.1.2. Adding the Dependency to the Project
8.1.3. Test the Dependency in the Project’s Dependencies
8.1.4. Test a Dependency in the Plugin’s Dependencies
8.1.5. Referencing classes in DSLs
9. Using the Pluggable Architecture
9.1. Custom Contract Converter
9.1.1. Pact Converter
9.1.2. Pact Contract
9.1.3. Pact for Producers
9.1.4. Pact for Consumers
9.2. Using the Custom Test Generator
9.3. Using the Custom Stub Generator
9.4. Using the Custom Stub Runner
9.5. Using the Custom Stub Downloader
10. Spring Cloud Contract WireMock
10.1. Registering Stubs Automatically
10.2. Using Files to Specify the Stub Bodies
10.3. Alternative: Using JUnit Rules
10.4. Relaxed SSL Validation for Rest Template
10.5. WireMock and Spring MVC Mocks
10.6. Generating Stubs using REST Docs
10.7. Generating Contracts by Using REST Docs
11. Migrations
11.1. 1.0.x → 1.1.x
11.1.1. New structure of generated stubs
11.2. 1.1.x → 1.2.x
11.2.1. Custom HttpServerStub
11.2.2. New packages for generated tests
11.2.3. New Methods in TemplateProcessor
11.2.4. RestAssured 3.0
11.3. 1.2.x → 2.0.x
11.3.1. No Camel support
12. 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.0.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),
@@ -1766,7 +1766,7 @@ the Stub Runner server. It will be available at port 8750<
 			def response = RestAssuredMockMvc.get("/stubs/${stubId}")
 		then:
 			response.statusCode == 200
-			response.body.as(Integer) > 0
+			Integer.valueOf(response.body.asString()) > 0
 		where:
 			stubId << ['org.springframework.cloud.contract.verifier.stubs:bootService:+:stubs',
 					   'org.springframework.cloud.contract.verifier.stubs:bootService:0.0.1-SNAPSHOT:stubs',
@@ -2494,7 +2494,7 @@ such as named("fileName", "fileContent"), or via a
   },
   "response" : {
 	"status" : 200,
-	"transformers" : [ "response-template" ]
+	"transformers" : [ "response-template", "foo-transformer" ]
   }
 }
 	'''

7.4 Response

The response must contain an HTTP status code and may contain other information. The @@ -2905,7 +2905,16 @@ in sending the following response body:

}
[Important]Important

This feature works only with WireMock having a version greater than or equal to 2.5.1. The Spring Cloud Contract Verifier uses WireMock’s response-template response transformer. It uses Handlebars to convert the Mustache {{{ }}} templates into -proper values. Additionally, it registers two helper functions:

7.5.6 Dynamic Properties in the Matchers Sections

If you work with Pact, the following discussion may seem familiar. +proper values. Additionally, it registers two helper functions:

7.5.6 Registering Your Own WireMock Extension

WireMock lets you register custom extensions. By default, Spring Cloud Contract registers +the transformer, which lets you reference a request from a response. If you want to +provide your own extensions, you can register an implementation of the +org.springframework.cloud.contract.verifier.dsl.wiremock.WireMockExtensions interface. +Since we use the spring.factories extension approach, you can create an entry in +META-INF/spring.factories file similar to the following:

org.springframework.cloud.contract.verifier.dsl.wiremock.WireMockExtensions=\
+org.springframework.cloud.contract.stubrunner.provider.wiremock.TestWireMockExtensions

The following is an example of a custom extension:

TestWireMockExtensions.groovy.  +

Unresolved directive in verifier_contract.adoc - include::../../../../spring-cloud-contract-stub-runner/src/test/groovy/org/springframework/cloud/contract/verifier/dsl/wiremock/TestWireMockExtensions.groovy[indent=0]

+

[Important]Important

Remember to override the applyGlobally() method and set it to false if you +want the transformation to be applied only for a mapping that explicitly requires it.

7.5.7 Dynamic Properties in the Matchers Sections

If you work with Pact, the following discussion may seem familiar. Quite a few users are used to having a separation between the body and setting the dynamic parts of a contract.

You can use two separate sections:

The following example shows a typical spring.factories file:

# Converters
 org.springframework.cloud.contract.spec.ContractConverter=\
-org.springframework.cloud.contract.verifier.converter.YamlContractConverter

The following example shows a typical YAML implementation that matches the preceding +org.springframework.cloud.contract.verifier.converter.YamlContractConverter + +# tag::extension[] +org.springframework.cloud.contract.verifier.dsl.wiremock.WireMockExtensions=\ +org.springframework.cloud.contract.verifier.dsl.wiremock.TestWireMockExtensions +# end::extension[]

The following example shows a typical YAML implementation that matches the preceding example:

package org.springframework.cloud.contract.verifier.converter
 
 import java.nio.file.Files
diff --git a/2.0.x/spring-cloud-contract-maven-plugin/checkstyle.html b/2.0.x/spring-cloud-contract-maven-plugin/checkstyle.html
index 1b47c8878b..358ace9a6d 100644
--- a/2.0.x/spring-cloud-contract-maven-plugin/checkstyle.html
+++ b/2.0.x/spring-cloud-contract-maven-plugin/checkstyle.html
@@ -1,13 +1,13 @@
 
 
 
   
     
     
-    
+    
     
     Spring Cloud Contract Maven Plugin – Checkstyle Results
     
@@ -146,7 +146,7 @@