From 96a13cf1181d08091b2c6f4a18ba7602c3e5a859 Mon Sep 17 00:00:00 2001 From: Marcin Grzejszczak Date: Mon, 2 Apr 2018 22:55:43 +0200 Subject: [PATCH] Sync docs from master to gh-pages --- multi/multi__spring_cloud_contract_faq.html | 138 ++++++++- ...lti__using_the_pluggable_architecture.html | 36 ++- multi/multi_spring-cloud-contract.html | 2 +- single/spring-cloud-contract.html | 176 ++++++++++- .../checkstyle.rss | 32 +- spring-cloud-contract.xml | 290 +++++++++++++++++- 6 files changed, 627 insertions(+), 47 deletions(-) diff --git a/multi/multi__spring_cloud_contract_faq.html b/multi/multi__spring_cloud_contract_faq.html index d7e6aff236..bb0999e170 100644 --- a/multi/multi__spring_cloud_contract_faq.html +++ b/multi/multi__spring_cloud_contract_faq.html @@ -115,7 +115,7 @@ one to one to the contents of the repo.

Example of a <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> - <version>2.0.0.BUILD-SNAPSHOT</version> + <version>2.0.0.RELEASE</version> <relativePath /> </parent> @@ -504,11 +504,141 @@ SCM repository, prefixed with the protocol. For example

"com.example:bookstore:0.0.1.RELEASE"
 )

With such a setup:

3.7 How can I debug the request/response being sent by the generated tests client?

The generated tests all boil down to RestAssured in some form or fashion which relies on Apache HttpClient. HttpClient has a facility called wire logging which logs the entire request and response to HttpClient. Spring Boot has a logging common application property for doing this sort of thing, just add this to your application properties

logging.level.org.apache.http.wire=DEBUG

3.7.1 How can I debug the mapping/request/response being sent by WireMock?

Starting from version 1.2.0 we turn on WireMock logging to +META-INF/com.example/foo/1.0.0/

  • Stub servers will be started and fed with mappings
  • Messaging definitions will be read and used in the messaging tests

    • 3.7 Can I use the Pact Broker?

    When using Pact you can use the Pact Broker +to store and share Pact definitions. Starting from Spring Cloud Contract +2.0.0 one can fetch Pact files from the Pact Broker to generate +tests and stubs.

    As a prerequisite the Pact Converter and Pact Stub Downloader +are required. You have to add it via the spring-cloud-contract-pact dependency. +You can read more about it in the Section 10.1.1, “Pact Converter” section.

    [Important]Important

    Pact follows the Consumer Contract convention. That means +that the Consumer creates the Pact definitions first, then +shares the files with the Producer. Those expectations are generated +from the Consumer’s code and can break the Producer if the expectation +is not met.

    3.7.1 Pact Consumer

    The consumer uses Pact framework to generate Pact files. The +Pact files are sent to the Pact Broker. An example of such +setup can be found here.

    3.7.2 Producer

    For the producer, to use the Pact files from the Pact Broker, we can reuse the +same mechanism we use for external contracts. We route Spring Cloud Contract +to use the Pact implementation via the URL that contains +the pact:// protocol. It’s enough to pass the URL to the +Pact Broker.

    Maven.  +

    <plugin>
+    <groupId>org.springframework.cloud</groupId>
+    <artifactId>spring-cloud-contract-maven-plugin</artifactId>
+    <version>${spring-cloud-contract.version}</version>
+    <extensions>true</extensions>
+    <configuration>
+        <!-- Base class mappings etc. -->
+
+        <!-- We want to pick contracts from a Git repository -->
+        <contractsRepositoryUrl>pact://http://localhost:8085</contractsRepositoryUrl>
+
+        <!-- We reuse the contract dependency section to set up the path
+        to the folder that contains the contract definitions. In our case the
+        path will be /groupId/artifactId/version/contracts -->
+        <contractDependency>
+            <groupId>${project.groupId}</groupId>
+            <artifactId>${project.artifactId}</artifactId>
+            <!-- When + is passed, a latest tag will be applied when fetching pacts -->
+            <version>+</version>
+        </contractDependency>
+
+        <!-- The contracts mode can't be classpath -->
+        <contractsMode>REMOTE</contractsMode>
+    </configuration>
+    <!-- Don't forget to add spring-cloud-contract-pact to the classpath! -->
+    <dependencies>
+        <dependency>
+            <groupId>org.springframework.cloud</groupId>
+            <artifactId>spring-cloud-contract-pact</artifactId>
+            <version>${spring-cloud-contract.version}</version>
+        </dependency>
+    </dependencies>
+</plugin>

    +

    Gradle.  +

    buildscript {
+	repositories {
+		//...
+	}
+
+	dependencies {
+		// ...
+		// Don't forget to add spring-cloud-contract-pact to the classpath!
+		classpath "org.springframework.cloud:spring-cloud-contract-pact:${contractVersion}"
+	}
+}
+
+contracts {
+	// When + is passed, a latest tag will be applied when fetching pacts
+	contractDependency {
+		stringNotation = "${project.group}:${project.name}:+"
+	}
+	contractRepository {
+		repositoryUrl = "pact://http://localhost:8085"
+	}
+	// The mode can't be classpath
+	contractsMode = "REMOTE"
+	// Base class mappings etc.
+}

    +

    With such a setup:

    • Pact files will be downloaded from the Pact Broker
    • Spring Cloud Contract will convert the Pact files into tests and stubs
    • The JAR with the stubs gets automatically created as usual

    3.7.3 Pact Consumer (Producer Contract approach)

    In the scenario where you don’t want to do Consumer Contract approach +(for every single consumer define the expectations) but you’d prefer +to do Producer Contracts (the producer provides the contracts and +publishes stubs), it’s enough to use Spring Cloud Contract with +Stub Runner option.

    First, remember to add Stub Runner and Spring Cloud Contract Pact module +as test dependencies.

    Maven.  +

    <dependencyManagement>
+    <dependencies>
+        <dependency>
+            <groupId>org.springframework.cloud</groupId>
+            <artifactId>spring-cloud-dependencies</artifactId>
+            <version>${spring-cloud.version}</version>
+            <type>pom</type>
+            <scope>import</scope>
+        </dependency>
+    </dependencies>
+</dependencyManagement>
+
+<!-- Don't forget to add spring-cloud-contract-pact to the classpath! -->
+<dependencies>
+    <!-- ... -->
+    <dependency>
+        <groupId>org.springframework.cloud</groupId>
+        <artifactId>spring-cloud-starter-contract-stub-runner</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.cloud</groupId>
+        <artifactId>spring-cloud-contract-pact</artifactId>
+        <scope>test</scope>
+    </dependency>
+</dependencies>

    +

    Gradle.  +

    dependencyManagement {
+    imports {
+        mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
+    }
+}
+
+dependencies {
+    //...
+    testCompile("org.springframework.cloud:spring-cloud-starter-contract-stub-runner")
+    // Don't forget to add spring-cloud-contract-pact to the classpath!
+    testCompile("org.springframework.cloud:spring-cloud-contract-pact")
+}

    +

    Next, just pass the URL of the Pact Broker to repositoryRoot, prefixed +with pact:// protocol. E.g. pact://http://localhost:8085

    @RunWith(SpringRunner.class)
+@SpringBootTest
+@AutoConfigureStubRunner(stubsMode = StubRunnerProperties.StubsMode.REMOTE,
+		ids = "com.example:beer-api-producer-pact",
+		repositoryRoot = "pact://http://localhost:8085")
+public class BeerControllerTest {
+    //Inject the port of the running stub
+    @StubRunnerPort("beer-api-producer-pact") int producerPort;
+    //...
+}

    With such a setup:

    • Pact files will be downloaded from the Pact Broker
    • Spring Cloud Contract will convert the Pact files into stub definitions
    • The stub servers will be started and fed with stubs

    For more information about Pact support you can go to +the Section 10.7, “Using the Pact Stub Downloader” section.

    3.8 How can I debug the request/response being sent by the generated tests client?

    The generated tests all boil down to RestAssured in some form or fashion which relies on Apache HttpClient. HttpClient has a facility called wire logging which logs the entire request and response to HttpClient. Spring Boot has a logging common application property for doing this sort of thing, just add this to your application properties

    logging.level.org.apache.http.wire=DEBUG

    3.8.1 How can I debug the mapping/request/response being sent by WireMock?

    Starting from version 1.2.0 we turn on WireMock logging to info and the WireMock notifier to being verbose. Now you will exactly know what request was received by WireMock server and which -matching response definition was picked.

    To turn off this feature just bump WireMock logging to ERROR

    logging.level.com.github.tomakehurst.wiremock=ERROR

    3.7.2 How can I see what got registered in the HTTP server stub?

    You can use the mappingsOutputFolder property on @AutoConfigureStubRunner or StubRunnerRule +matching response definition was picked.

    To turn off this feature just bump WireMock logging to ERROR

    logging.level.com.github.tomakehurst.wiremock=ERROR

    3.8.2 How can I see what got registered in the HTTP server stub?

    You can use the mappingsOutputFolder property on @AutoConfigureStubRunner or StubRunnerRule to dump all mappings per artifact id. Also the port at which the given stub server was -started will be attached.

    3.7.3 Can I reference text from file?

    Yes! With version 1.2.0 we’ve added such a possibility. It’s enough to call file(…​) method in the +started will be attached.

    3.8.3 Can I reference text from file?

    Yes! With version 1.2.0 we’ve added such a possibility. It’s enough to call file(…​) method in the DSL and provide a path relative to where the contract lays. If you’re using YAML just use the bodyFromFile property.

    Prev   Next
    2. Spring Cloud Contract Verifier Introduction Home 4. Spring Cloud Contract Verifier Setup
    \ 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 0513301f81..a04d64a99f 100644 --- a/multi/multi__using_the_pluggable_architecture.html +++ b/multi/multi__using_the_pluggable_architecture.html @@ -47,7 +47,7 @@ structure converter. The following code listing shows the conversion. Also, you must define how to perform that conversion in both directions.

    [Important]Important

    Once you create your implementation, you must create a /META-INF/spring.factories file in which you provide the fully qualified name of your implementation.

    The following example shows a typical spring.factories file:

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

    10.1.1 Pact Converter

    Spring Cloud Contract includes support for Pact representation of +org.springframework.cloud.contract.verifier.converter.YamlContractConverter

    10.1.1 Pact Converter

    Spring Cloud Contract includes support for Pact representation of contracts up until v4. Instead of using the Groovy DSL, you can use Pact files. In this section, we present how to add Pact support for your project. Note however that not all functionality is supported. Starting with v3 you can combine multiple matcher for the same element; @@ -167,7 +167,7 @@ the current Pact version that you use.

    Maven.  <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> - <artifactId>spring-cloud-contract-spec-pact</artifactId> + <artifactId>spring-cloud-contract-pact</artifactId> <version>${spring-cloud-contract.version}</version> </dependency> <dependency> @@ -178,7 +178,7 @@ the current Pact version that you use.

    Maven.  </dependencies> </plugin>

    Gradle.  -

    classpath "org.springframework.cloud:spring-cloud-contract-spec-pact:${findProperty('verifierVersion') ?: verifierVersion}"
+
    classpath "org.springframework.cloud:spring-cloud-contract-pact:${findProperty('verifierVersion') ?: verifierVersion}"
 classpath 'au.com.dius:pact-jvm-model:3.5.13'
    
 
    When you execute the build of your application, a test will be generated. The generated
 test might be as follows:
    @Test
@@ -230,7 +230,7 @@ dependencies. One is the Spring Cloud Contract Pact support, and the other repre
 current Pact version that you use.
    Maven. 
 
    <dependency>
 	<groupId>org.springframework.cloud</groupId>
-	<artifactId>spring-cloud-contract-spec-pact</artifactId>
+	<artifactId>spring-cloud-contract-pact</artifactId>
 	<scope>test</scope>
 </dependency>
 <dependency>
@@ -240,7 +240,7 @@ current Pact version that you use.
    Maven. 
 	<scope>test</scope>
 </dependency>
    
 
    Gradle. 
-
    testCompile "org.springframework.cloud:spring-cloud-contract-spec-pact"
+
    testCompile "org.springframework.cloud:spring-cloud-contract-pact"
 testCompile 'au.com.dius:pact-jvm-model:3.5.13'

    10.2 Using the Custom Test Generator

    If you want to generate tests for languages other than Java or you are not happy with the way the verifier builds Java tests, you can register your own implementation.

    The SingleTestGenerator interface lets you register your own implementation. The @@ -434,7 +434,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) @@ -444,4 +444,26 @@ properties

    stubrunner.properties.git.no-of-attempts (system prop) * STUBRUNNER_PROPERTIES_GIT_NO_OF_ATTEMPTS (env prop)

    10

    Number of attempts to push the commits to origin

    * git.wait-between-attempts (Plugin prop) * stubrunner.properties.git.wait-between-attempts (system prop) -* STUBRUNNER_PROPERTIES_GIT_WAIT_BETWEEN_ATTEMPTS (env prop)

    1000

    Number of millis to wait between attempts to push the commits to origin


    Prev   Next
    9. Customization Home 11. Spring Cloud Contract WireMock
    \ No newline at end of file +* STUBRUNNER_PROPERTIES_GIT_WAIT_BETWEEN_ATTEMPTS (env prop)

    1000

    Number of millis to wait between attempts to push the commits to origin


    10.7 Using the Pact Stub Downloader

    Whenever the repositoryRoot starts with a Pact protocol +(starts with pact://), the stub downloader will try +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

    Type of a property

    Name of the property

    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) +* STUBRUNNER_PROPERTIES_PACTBROKER_PORT (env prop)

    Port from URL passed to repositoryRoot

    What is the port of Pact Broker

    * pactbroker.protocol (plugin prop) +* stubrunner.properties.pactbroker.protocol (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_PROTOCOL (env prop)

    Protocol from URL passed to repositoryRoot

    What is the protocol of Pact Broker

    * pactbroker.tags (plugin prop) +* stubrunner.properties.pactbroker.tags (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_TAGS (env prop)

    Version of the stub, or latest if version is +

    What tags should be used to fetch the stub

    * pactbroker.auth.scheme (plugin prop) +* stubrunner.properties.pactbroker.auth.scheme (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_SCHEME (env prop)

    Basic

    What kind of authentication should be used to connect to the Pact Broker

    * pactbroker.auth.username (plugin prop) +* stubrunner.properties.pactbroker.auth.username (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_USERNAME (env prop)

    		 

    Username used to connect to the Pact Broker

    * pactbroker.auth.password (plugin prop) +* stubrunner.properties.pactbroker.auth.password (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_PASSWORD (env prop)

    		 

    Password used to connect to the Pact Broker

    * pactbroker.provider-name-with-group-id (plugin prop) +* stubrunner.properties.pactbroker.provider-name-with-group-id (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_PROVIDER_NAME_WITH_GROUP_ID (env prop)

    false

    When true, the provider name will be a combination of groupId:artifactId. If false, just artifactId is used


    Prev   Next
    9. Customization Home 11. Spring Cloud Contract WireMock
    \ No newline at end of file diff --git a/multi/multi_spring-cloud-contract.html b/multi/multi_spring-cloud-contract.html index a7341f3b71..7cc9de1801 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. 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 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. 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
    10.6. Using the SCM 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. 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. 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
    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 ac92a860e1..bef2139ebb 100644 --- a/single/spring-cloud-contract.html +++ b/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. 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. 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 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. 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
    10.6. Using the SCM 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. 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. 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
    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.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), @@ -896,7 +896,7 @@ one to one to the contents of the repo.

    Example of a <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> - <version>2.0.0.BUILD-SNAPSHOT</version> + <version>2.0.0.RELEASE</version> <relativePath /> </parent> @@ -1285,12 +1285,142 @@ SCM repository, prefixed with the protocol. For example

    "com.example:bookstore:0.0.1.RELEASE"
 )

    With such a setup:

    • Git project will be cloned to a temporary directory
    • The SCM stub downloader will go to META-INF/groupId/artifactId/version/ folder to find stub definitions and contracts. E.g. for com.example:foo:1.0.0 the path would be -META-INF/com.example/foo/1.0.0/
    • Stub servers will be started and fed with mappings
    • Messaging definitions will be read and used in the messaging tests

    3.7 How can I debug the request/response being sent by the generated tests client?

    The generated tests all boil down to RestAssured in some form or fashion which relies on Apache HttpClient. HttpClient has a facility called wire logging which logs the entire request and response to HttpClient. Spring Boot has a logging common application property for doing this sort of thing, just add this to your application properties

    logging.level.org.apache.http.wire=DEBUG

    3.7.1 How can I debug the mapping/request/response being sent by WireMock?

    Starting from version 1.2.0 we turn on WireMock logging to +META-INF/com.example/foo/1.0.0/

  • Stub servers will be started and fed with mappings
  • Messaging definitions will be read and used in the messaging tests

    • 3.7 Can I use the Pact Broker?

    When using Pact you can use the Pact Broker +to store and share Pact definitions. Starting from Spring Cloud Contract +2.0.0 one can fetch Pact files from the Pact Broker to generate +tests and stubs.

    As a prerequisite the Pact Converter and Pact Stub Downloader +are required. You have to add it via the spring-cloud-contract-pact dependency. +You can read more about it in the Section 10.1.1, “Pact Converter” section.

    [Important]Important

    Pact follows the Consumer Contract convention. That means +that the Consumer creates the Pact definitions first, then +shares the files with the Producer. Those expectations are generated +from the Consumer’s code and can break the Producer if the expectation +is not met.

    3.7.1 Pact Consumer

    The consumer uses Pact framework to generate Pact files. The +Pact files are sent to the Pact Broker. An example of such +setup can be found here.

    3.7.2 Producer

    For the producer, to use the Pact files from the Pact Broker, we can reuse the +same mechanism we use for external contracts. We route Spring Cloud Contract +to use the Pact implementation via the URL that contains +the pact:// protocol. It’s enough to pass the URL to the +Pact Broker.

    Maven.  +

    <plugin>
+    <groupId>org.springframework.cloud</groupId>
+    <artifactId>spring-cloud-contract-maven-plugin</artifactId>
+    <version>${spring-cloud-contract.version}</version>
+    <extensions>true</extensions>
+    <configuration>
+        <!-- Base class mappings etc. -->
+
+        <!-- We want to pick contracts from a Git repository -->
+        <contractsRepositoryUrl>pact://http://localhost:8085</contractsRepositoryUrl>
+
+        <!-- We reuse the contract dependency section to set up the path
+        to the folder that contains the contract definitions. In our case the
+        path will be /groupId/artifactId/version/contracts -->
+        <contractDependency>
+            <groupId>${project.groupId}</groupId>
+            <artifactId>${project.artifactId}</artifactId>
+            <!-- When + is passed, a latest tag will be applied when fetching pacts -->
+            <version>+</version>
+        </contractDependency>
+
+        <!-- The contracts mode can't be classpath -->
+        <contractsMode>REMOTE</contractsMode>
+    </configuration>
+    <!-- Don't forget to add spring-cloud-contract-pact to the classpath! -->
+    <dependencies>
+        <dependency>
+            <groupId>org.springframework.cloud</groupId>
+            <artifactId>spring-cloud-contract-pact</artifactId>
+            <version>${spring-cloud-contract.version}</version>
+        </dependency>
+    </dependencies>
+</plugin>

    +

    Gradle.  +

    buildscript {
+	repositories {
+		//...
+	}
+
+	dependencies {
+		// ...
+		// Don't forget to add spring-cloud-contract-pact to the classpath!
+		classpath "org.springframework.cloud:spring-cloud-contract-pact:${contractVersion}"
+	}
+}
+
+contracts {
+	// When + is passed, a latest tag will be applied when fetching pacts
+	contractDependency {
+		stringNotation = "${project.group}:${project.name}:+"
+	}
+	contractRepository {
+		repositoryUrl = "pact://http://localhost:8085"
+	}
+	// The mode can't be classpath
+	contractsMode = "REMOTE"
+	// Base class mappings etc.
+}

    +

    With such a setup:

    • Pact files will be downloaded from the Pact Broker
    • Spring Cloud Contract will convert the Pact files into tests and stubs
    • The JAR with the stubs gets automatically created as usual

    3.7.3 Pact Consumer (Producer Contract approach)

    In the scenario where you don’t want to do Consumer Contract approach +(for every single consumer define the expectations) but you’d prefer +to do Producer Contracts (the producer provides the contracts and +publishes stubs), it’s enough to use Spring Cloud Contract with +Stub Runner option.

    First, remember to add Stub Runner and Spring Cloud Contract Pact module +as test dependencies.

    Maven.  +

    <dependencyManagement>
+    <dependencies>
+        <dependency>
+            <groupId>org.springframework.cloud</groupId>
+            <artifactId>spring-cloud-dependencies</artifactId>
+            <version>${spring-cloud.version}</version>
+            <type>pom</type>
+            <scope>import</scope>
+        </dependency>
+    </dependencies>
+</dependencyManagement>
+
+<!-- Don't forget to add spring-cloud-contract-pact to the classpath! -->
+<dependencies>
+    <!-- ... -->
+    <dependency>
+        <groupId>org.springframework.cloud</groupId>
+        <artifactId>spring-cloud-starter-contract-stub-runner</artifactId>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.cloud</groupId>
+        <artifactId>spring-cloud-contract-pact</artifactId>
+        <scope>test</scope>
+    </dependency>
+</dependencies>

    +

    Gradle.  +

    dependencyManagement {
+    imports {
+        mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
+    }
+}
+
+dependencies {
+    //...
+    testCompile("org.springframework.cloud:spring-cloud-starter-contract-stub-runner")
+    // Don't forget to add spring-cloud-contract-pact to the classpath!
+    testCompile("org.springframework.cloud:spring-cloud-contract-pact")
+}

    +

    Next, just pass the URL of the Pact Broker to repositoryRoot, prefixed +with pact:// protocol. E.g. pact://http://localhost:8085

    @RunWith(SpringRunner.class)
+@SpringBootTest
+@AutoConfigureStubRunner(stubsMode = StubRunnerProperties.StubsMode.REMOTE,
+		ids = "com.example:beer-api-producer-pact",
+		repositoryRoot = "pact://http://localhost:8085")
+public class BeerControllerTest {
+    //Inject the port of the running stub
+    @StubRunnerPort("beer-api-producer-pact") int producerPort;
+    //...
+}

    With such a setup:

    • Pact files will be downloaded from the Pact Broker
    • Spring Cloud Contract will convert the Pact files into stub definitions
    • The stub servers will be started and fed with stubs

    For more information about Pact support you can go to +the Section 10.7, “Using the Pact Stub Downloader” section.

    3.8 How can I debug the request/response being sent by the generated tests client?

    The generated tests all boil down to RestAssured in some form or fashion which relies on Apache HttpClient. HttpClient has a facility called wire logging which logs the entire request and response to HttpClient. Spring Boot has a logging common application property for doing this sort of thing, just add this to your application properties

    logging.level.org.apache.http.wire=DEBUG

    3.8.1 How can I debug the mapping/request/response being sent by WireMock?

    Starting from version 1.2.0 we turn on WireMock logging to info and the WireMock notifier to being verbose. Now you will exactly know what request was received by WireMock server and which -matching response definition was picked.

    To turn off this feature just bump WireMock logging to ERROR

    logging.level.com.github.tomakehurst.wiremock=ERROR

    3.7.2 How can I see what got registered in the HTTP server stub?

    You can use the mappingsOutputFolder property on @AutoConfigureStubRunner or StubRunnerRule +matching response definition was picked.

    To turn off this feature just bump WireMock logging to ERROR

    logging.level.com.github.tomakehurst.wiremock=ERROR

    3.8.2 How can I see what got registered in the HTTP server stub?

    You can use the mappingsOutputFolder property on @AutoConfigureStubRunner or StubRunnerRule to dump all mappings per artifact id. Also the port at which the given stub server was -started will be attached.

    3.7.3 Can I reference text from file?

    Yes! With version 1.2.0 we’ve added such a possibility. It’s enough to call file(…​) method in the +started will be attached.

    3.8.3 Can I reference text from file?

    Yes! With version 1.2.0 we’ve added such a possibility. It’s enough to call file(…​) method in the DSL and provide a path relative to where the contract lays. If you’re using YAML just use the bodyFromFile property.

    4. Spring Cloud Contract Verifier Setup

    You can set up Spring Cloud Contract Verifier in the following ways:

    4.1 Gradle Project

    To learn how to set up the Gradle project for Spring Cloud Contract Verifier, read the following sections:

    4.1.1 Prerequisites

    In order to use Spring Cloud Contract Verifier with WireMock, you muse use either a @@ -5313,7 +5443,7 @@ structure converter. The following code listing shows the conversion. Also, you must define how to perform that conversion in both directions.

    [Important]Important

    Once you create your implementation, you must create a /META-INF/spring.factories file in which you provide the fully qualified name of your implementation.

    The following example shows a typical spring.factories file:

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

    10.1.1 Pact Converter

    Spring Cloud Contract includes support for Pact representation of +org.springframework.cloud.contract.verifier.converter.YamlContractConverter

    10.1.1 Pact Converter

    Spring Cloud Contract includes support for Pact representation of contracts up until v4. Instead of using the Groovy DSL, you can use Pact files. In this section, we present how to add Pact support for your project. Note however that not all functionality is supported. Starting with v3 you can combine multiple matcher for the same element; @@ -5433,7 +5563,7 @@ the current Pact version that you use.

    Maven.  <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> - <artifactId>spring-cloud-contract-spec-pact</artifactId> + <artifactId>spring-cloud-contract-pact</artifactId> <version>${spring-cloud-contract.version}</version> </dependency> <dependency> @@ -5444,7 +5574,7 @@ the current Pact version that you use.

    Maven.  </dependencies> </plugin>

    Gradle.  -

    classpath "org.springframework.cloud:spring-cloud-contract-spec-pact:${findProperty('verifierVersion') ?: verifierVersion}"
+
    classpath "org.springframework.cloud:spring-cloud-contract-pact:${findProperty('verifierVersion') ?: verifierVersion}"
 classpath 'au.com.dius:pact-jvm-model:3.5.13'
    
 
    When you execute the build of your application, a test will be generated. The generated
 test might be as follows:
    @Test
@@ -5496,7 +5626,7 @@ dependencies. One is the Spring Cloud Contract Pact support, and the other repre
 current Pact version that you use.
    Maven. 
 
    <dependency>
 	<groupId>org.springframework.cloud</groupId>
-	<artifactId>spring-cloud-contract-spec-pact</artifactId>
+	<artifactId>spring-cloud-contract-pact</artifactId>
 	<scope>test</scope>
 </dependency>
 <dependency>
@@ -5506,7 +5636,7 @@ current Pact version that you use.
    Maven. 
 	<scope>test</scope>
 </dependency>
    
 
    Gradle. 
-
    testCompile "org.springframework.cloud:spring-cloud-contract-spec-pact"
+
    testCompile "org.springframework.cloud:spring-cloud-contract-pact"
 testCompile 'au.com.dius:pact-jvm-model:3.5.13'

    10.2 Using the Custom Test Generator

    If you want to generate tests for languages other than Java or you are not happy with the way the verifier builds Java tests, you can register your own implementation.

    The SingleTestGenerator interface lets you register your own implementation. The @@ -5700,7 +5830,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) @@ -5710,7 +5840,29 @@ properties

    stubrunner.properties.git.no-of-attempts (system prop) * STUBRUNNER_PROPERTIES_GIT_NO_OF_ATTEMPTS (env prop)

    10

    Number of attempts to push the commits to origin

    * git.wait-between-attempts (Plugin prop) * stubrunner.properties.git.wait-between-attempts (system prop) -* STUBRUNNER_PROPERTIES_GIT_WAIT_BETWEEN_ATTEMPTS (env prop)

    1000

    Number of millis to wait between attempts to push the commits to origin


    11. Spring Cloud Contract WireMock

    The Spring Cloud Contract WireMock modules let you use WireMock in a +* STUBRUNNER_PROPERTIES_GIT_WAIT_BETWEEN_ATTEMPTS (env prop)

    1000

    Number of millis to wait between attempts to push the commits to origin


    10.7 Using the Pact Stub Downloader

    Whenever the repositoryRoot starts with a Pact protocol +(starts with pact://), the stub downloader will try +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

    Type of a property

    Name of the property

    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) +* STUBRUNNER_PROPERTIES_PACTBROKER_PORT (env prop)

    Port from URL passed to repositoryRoot

    What is the port of Pact Broker

    * pactbroker.protocol (plugin prop) +* stubrunner.properties.pactbroker.protocol (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_PROTOCOL (env prop)

    Protocol from URL passed to repositoryRoot

    What is the protocol of Pact Broker

    * pactbroker.tags (plugin prop) +* stubrunner.properties.pactbroker.tags (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_TAGS (env prop)

    Version of the stub, or latest if version is +

    What tags should be used to fetch the stub

    * pactbroker.auth.scheme (plugin prop) +* stubrunner.properties.pactbroker.auth.scheme (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_SCHEME (env prop)

    Basic

    What kind of authentication should be used to connect to the Pact Broker

    * pactbroker.auth.username (plugin prop) +* stubrunner.properties.pactbroker.auth.username (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_USERNAME (env prop)

    		 

    Username used to connect to the Pact Broker

    * pactbroker.auth.password (plugin prop) +* stubrunner.properties.pactbroker.auth.password (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_PASSWORD (env prop)

    		 

    Password used to connect to the Pact Broker

    * pactbroker.provider-name-with-group-id (plugin prop) +* stubrunner.properties.pactbroker.provider-name-with-group-id (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_PROVIDER_NAME_WITH_GROUP_ID (env prop)

    false

    When true, the provider name will be a combination of groupId:artifactId. If false, just artifactId is used


    11. Spring Cloud Contract WireMock

    The Spring Cloud Contract WireMock modules let you use WireMock in a Spring Boot application. Check out the samples for more details.

    If you have a Spring Boot application that uses Tomcat as an embedded server (which is diff --git a/spring-cloud-contract-maven-plugin/checkstyle.rss b/spring-cloud-contract-maven-plugin/checkstyle.rss index 6713ab69b6..5fcdcc33a1 100644 --- a/spring-cloud-contract-maven-plugin/checkstyle.rss +++ b/spring-cloud-contract-maven-plugin/checkstyle.rss @@ -46,7 +46,7 @@ under the License. - org/springframework/cloud/contract/maven/verifier/GenerateTestsMojo.java + org/springframework/cloud/contract/maven/verifier/MavenContractsDownloader.java 0 @@ -60,7 +60,7 @@ under the License. - org/springframework/cloud/contract/maven/verifier/MavenContractsDownloader.java + org/springframework/cloud/contract/maven/verifier/GenerateTestsMojo.java 0 @@ -127,6 +127,20 @@ under the License. 0 + + + + org/springframework/cloud/contract/maven/verifier/stubrunner/RemoteStubRunner.java + + + 0 + + + 0 + + + 0 + @@ -155,20 +169,6 @@ under the License. 0 - - - - org/springframework/cloud/contract/maven/verifier/stubrunner/RemoteStubRunner.java - - - 0 - - - 0 - - - 0 - diff --git a/spring-cloud-contract.xml b/spring-cloud-contract.xml index 307c48bf01..b4417205b2 100644 --- a/spring-cloud-contract.xml +++ b/spring-cloud-contract.xml @@ -4,7 +4,7 @@ Spring Cloud Contract -2018-04-02 +2018-03-31 @@ -1555,7 +1555,7 @@ one to one to the contents of the repo. <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> - <version>2.0.0.BUILD-SNAPSHOT</version> + <version>2.0.0.RELEASE</version> <relativePath /> </parent> @@ -2138,6 +2138,200 @@ to find stub definitions and contracts. E.g. for com.example:foo:1.0.0< +

    +Can I use the Pact Broker? +When using Pact you can use the Pact Broker +to store and share Pact definitions. Starting from Spring Cloud Contract +2.0.0 one can fetch Pact files from the Pact Broker to generate +tests and stubs. +As a prerequisite the Pact Converter and Pact Stub Downloader +are required. You have to add it via the spring-cloud-contract-pact dependency. +You can read more about it in the section. + +Pact follows the Consumer Contract convention. That means +that the Consumer creates the Pact definitions first, then +shares the files with the Producer. Those expectations are generated +from the Consumer’s code and can break the Producer if the expectation +is not met. + +
    +Pact Consumer +The consumer uses Pact framework to generate Pact files. The +Pact files are sent to the Pact Broker. An example of such +setup can be found here. +
    +
    +Producer +For the producer, to use the Pact files from the Pact Broker, we can reuse the +same mechanism we use for external contracts. We route Spring Cloud Contract +to use the Pact implementation via the URL that contains +the pact:// protocol. It’s enough to pass the URL to the +Pact Broker. + +Maven + +<plugin> + <groupId>org.springframework.cloud</groupId> + <artifactId>spring-cloud-contract-maven-plugin</artifactId> + <version>${spring-cloud-contract.version}</version> + <extensions>true</extensions> + <configuration> + <!-- Base class mappings etc. --> + + <!-- We want to pick contracts from a Git repository --> + <contractsRepositoryUrl>pact://http://localhost:8085</contractsRepositoryUrl> + + <!-- We reuse the contract dependency section to set up the path + to the folder that contains the contract definitions. In our case the + path will be /groupId/artifactId/version/contracts --> + <contractDependency> + <groupId>${project.groupId}</groupId> + <artifactId>${project.artifactId}</artifactId> + <!-- When + is passed, a latest tag will be applied when fetching pacts --> + <version>+</version> + </contractDependency> + + <!-- The contracts mode can't be classpath --> + <contractsMode>REMOTE</contractsMode> + </configuration> + <!-- Don't forget to add spring-cloud-contract-pact to the classpath! --> + <dependencies> + <dependency> + <groupId>org.springframework.cloud</groupId> + <artifactId>spring-cloud-contract-pact</artifactId> + <version>${spring-cloud-contract.version}</version> + </dependency> + </dependencies> +</plugin> + + + +Gradle + +buildscript { + repositories { + //... + } + + dependencies { + // ... + // Don't forget to add spring-cloud-contract-pact to the classpath! + classpath "org.springframework.cloud:spring-cloud-contract-pact:${contractVersion}" + } +} + +contracts { + // When + is passed, a latest tag will be applied when fetching pacts + contractDependency { + stringNotation = "${project.group}:${project.name}:+" + } + contractRepository { + repositoryUrl = "pact://http://localhost:8085" + } + // The mode can't be classpath + contractsMode = "REMOTE" + // Base class mappings etc. +} + + +With such a setup: + + +Pact files will be downloaded from the Pact Broker + + +Spring Cloud Contract will convert the Pact files into tests and stubs + + +The JAR with the stubs gets automatically created as usual + + +
    +
    +Pact Consumer (Producer Contract approach) +In the scenario where you don’t want to do Consumer Contract approach +(for every single consumer define the expectations) but you’d prefer +to do Producer Contracts (the producer provides the contracts and +publishes stubs), it’s enough to use Spring Cloud Contract with +Stub Runner option. +First, remember to add Stub Runner and Spring Cloud Contract Pact module +as test dependencies. + +Maven + +<dependencyManagement> + <dependencies> + <dependency> + <groupId>org.springframework.cloud</groupId> + <artifactId>spring-cloud-dependencies</artifactId> + <version>${spring-cloud.version}</version> + <type>pom</type> + <scope>import</scope> + </dependency> + </dependencies> +</dependencyManagement> + +<!-- Don't forget to add spring-cloud-contract-pact to the classpath! --> +<dependencies> + <!-- ... --> + <dependency> + <groupId>org.springframework.cloud</groupId> + <artifactId>spring-cloud-starter-contract-stub-runner</artifactId> + <scope>test</scope> + </dependency> + <dependency> + <groupId>org.springframework.cloud</groupId> + <artifactId>spring-cloud-contract-pact</artifactId> + <scope>test</scope> + </dependency> +</dependencies> + + + +Gradle + +dependencyManagement { + imports { + mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}" + } +} + +dependencies { + //... + testCompile("org.springframework.cloud:spring-cloud-starter-contract-stub-runner") + // Don't forget to add spring-cloud-contract-pact to the classpath! + testCompile("org.springframework.cloud:spring-cloud-contract-pact") +} + + +Next, just pass the URL of the Pact Broker to repositoryRoot, prefixed +with pact:// protocol. E.g. pact://http://localhost:8085 +@RunWith(SpringRunner.class) +@SpringBootTest +@AutoConfigureStubRunner(stubsMode = StubRunnerProperties.StubsMode.REMOTE, + ids = "com.example:beer-api-producer-pact", + repositoryRoot = "pact://http://localhost:8085") +public class BeerControllerTest { + //Inject the port of the running stub + @StubRunnerPort("beer-api-producer-pact") int producerPort; + //... +} +With such a setup: + + +Pact files will be downloaded from the Pact Broker + + +Spring Cloud Contract will convert the Pact files into stub definitions + + +The stub servers will be started and fed with stubs + + +For more information about Pact support you can go to +the section. +
    +
    How can I debug the request/response being sent by the generated tests client? The generated tests all boil down to RestAssured in some form or fashion which relies on Apache HttpClient. HttpClient has a facility called wire logging which logs the entire request and response to HttpClient. Spring Boot has a logging common application property for doing this sort of thing, just add this to your application properties @@ -8518,7 +8712,7 @@ implementation. The following example shows a typical spring.factories file: org.springframework.cloud.contract.spec.ContractConverter=\ org.springframework.cloud.contract.verifier.converter.YamlContractConverter -
    +
    Pact Converter Spring Cloud Contract includes support for Pact representation of contracts up until v4. Instead of using the Groovy DSL, you can use Pact files. In this section, we @@ -8653,7 +8847,7 @@ the current Pact version that you use. <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> - <artifactId>spring-cloud-contract-spec-pact</artifactId> + <artifactId>spring-cloud-contract-pact</artifactId> <version>${spring-cloud-contract.version}</version> </dependency> <dependency> @@ -8668,7 +8862,7 @@ the current Pact version that you use. Gradle -classpath "org.springframework.cloud:spring-cloud-contract-spec-pact:${findProperty('verifierVersion') ?: verifierVersion}" +classpath "org.springframework.cloud:spring-cloud-contract-pact:${findProperty('verifierVersion') ?: verifierVersion}" classpath 'au.com.dius:pact-jvm-model:3.5.13' @@ -8732,7 +8926,7 @@ current Pact version that you use. <dependency> <groupId>org.springframework.cloud</groupId> - <artifactId>spring-cloud-contract-spec-pact</artifactId> + <artifactId>spring-cloud-contract-pact</artifactId> <scope>test</scope> </dependency> <dependency> @@ -8746,7 +8940,7 @@ current Pact version that you use. Gradle -testCompile "org.springframework.cloud:spring-cloud-contract-spec-pact" +testCompile "org.springframework.cloud:spring-cloud-contract-pact" testCompile 'au.com.dius:pact-jvm-model:3.5.13' @@ -9042,6 +9236,88 @@ properties
    +
    +Using the Pact Stub Downloader +Whenever the repositoryRoot starts with a Pact protocol +(starts with pact://), the stub downloader will try +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 + +SCM Stub Downloader properties + + + + + + +Type of a property +Name of the property +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) +* STUBRUNNER_PROPERTIES_PACTBROKER_PORT (env prop) +Port from URL passed to repositoryRoot +What is the port of Pact Broker + + +* pactbroker.protocol (plugin prop) +* stubrunner.properties.pactbroker.protocol (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_PROTOCOL (env prop) +Protocol from URL passed to repositoryRoot +What is the protocol of Pact Broker + + +* pactbroker.tags (plugin prop) +* stubrunner.properties.pactbroker.tags (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_TAGS (env prop) +Version of the stub, or latest if version is + +What tags should be used to fetch the stub + + +* pactbroker.auth.scheme (plugin prop) +* stubrunner.properties.pactbroker.auth.scheme (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_SCHEME (env prop) +Basic +What kind of authentication should be used to connect to the Pact Broker + + +* pactbroker.auth.username (plugin prop) +* stubrunner.properties.pactbroker.auth.username (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_USERNAME (env prop) + +Username used to connect to the Pact Broker + + +* pactbroker.auth.password (plugin prop) +* stubrunner.properties.pactbroker.auth.password (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_PASSWORD (env prop) + +Password used to connect to the Pact Broker + + +* pactbroker.provider-name-with-group-id (plugin prop) +* stubrunner.properties.pactbroker.provider-name-with-group-id (system prop) +* STUBRUNNER_PROPERTIES_PACTBROKER_PROVIDER_NAME_WITH_GROUP_ID (env prop) +false +When true, the provider name will be a combination of groupId:artifactId. If false, just artifactId is used + + + +
    +
    Spring Cloud Contract WireMock