diff --git a/2.0.x/multi/multi__spring_cloud_contract_faq.html b/2.0.x/multi/multi__spring_cloud_contract_faq.html index 40ba7eb1a3..44afbb48f9 100644 --- a/2.0.x/multi/multi__spring_cloud_contract_faq.html +++ b/2.0.x/multi/multi__spring_cloud_contract_faq.html @@ -67,7 +67,7 @@ for time and UUID are simplified and most likely invalid but we want to keep thi body: "bar" ]) } -}
[Important]Important

Please read the Groovy docs related to JSON to understand how to +}

[Important]Important

Please read the Groovy docs related to JSON to understand how to properly structure the request / response bodies.

3.4 How to do Stubs versioning?

3.4.1 API Versioning

Let’s try to answer a question what versioning really means. If you’re referring to the API version then there are different approaches.

  • use Hypermedia, links and do not version your API by any means
  • pass versions through headers / urls

I will not try to answer a question which approach is better. Whatever suit your needs and allows you to generate business value should be picked.

Let’s assume that you do version your API. In that case you should provide as many contracts as many versions you support. diff --git a/2.0.x/multi/multi__spring_cloud_contract_stub_runner.html b/2.0.x/multi/multi__spring_cloud_contract_stub_runner.html index d0d92462d0..0fc1536fa9 100644 --- a/2.0.x/multi/multi__spring_cloud_contract_stub_runner.html +++ b/2.0.x/multi/multi__spring_cloud_contract_stub_runner.html @@ -246,7 +246,7 @@ HTTP stubs without the need to download artifacts.

HTTP Stubs

Stubs are defined in JSON documents, whose syntax is defined in WireMock documentation

Example:

{
+                                  repository

HTTP Stubs

Stubs are defined in JSON documents, whose syntax is defined in WireMock documentation

Example:

{
     "request": {
         "method": "GET",
         "url": "/ping"
@@ -630,7 +630,7 @@ the Stub Runner server. It will be available at port 8750<
 }

As you can see we want to start a Stub Runner Boot server @EnableStubRunnerServer, enable Eureka client @EnableEurekaClient and we want to have the stub runner feature turned on @AutoConfigureStubRunner.

Now let’s assume that we want to start this application so that the stubs get automatically registered. We can do it by running the app java -jar ${SYSTEM_PROPS} stub-runner-boot-eureka-example.jar where - ${SYSTEM_PROPS} would contain the following list of properties

-Dstubrunner.repositoryRoot=https://repo.spring.io/snapshots (1)
+ ${SYSTEM_PROPS} would contain the following list of properties
-Dstubrunner.repositoryRoot=https://repo.spring.io/snapshot (1)
 -Dstubrunner.cloud.stubbed.discovery.enabled=false (2)
 -Dstubrunner.ids=org.springframework.cloud.contract.verifier.stubs:loanIssuance,org.springframework.cloud.contract.verifier.stubs:fraudDetectionServer,org.springframework.cloud.contract.verifier.stubs:bootService (3)
 -Dstubrunner.idsToServiceIds.fraudDetectionServer=someNameThatShouldMapFraudDetectionServer (4)
diff --git a/2.0.x/multi/multi__spring_cloud_contract_verifier_introduction.html b/2.0.x/multi/multi__spring_cloud_contract_verifier_introduction.html
index 80b39ee594..3881e713a8 100644
--- a/2.0.x/multi/multi__spring_cloud_contract_verifier_introduction.html
+++ b/2.0.x/multi/multi__spring_cloud_contract_verifier_introduction.html
@@ -1,7 +1,7 @@
 
       
    2. Spring Cloud Contract Verifier Introduction
2. Spring Cloud Contract Verifier Introduction
Prev   Next
2. Spring Cloud Contract Verifier Introduction
[Tip]Tip
The Accurest project was initially started by Marcin Grzejszczak and Jakub Kubrynski
-(codearte.io)
Spring Cloud Contract Verifier enables Consumer Driven Contract (CDC) development of
+(Codearte)

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

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

2.5 Dependencies

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

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

2.6 Additional Links

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

2.6.1 Spring Cloud Contract video

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

2.6.2 Readings

2.7 Samples

You can find some samples at +constant development.

2.6.1 Spring Cloud Contract video

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

2.6.2 Readings

2.7 Samples

You can find some samples at samples.

Prev   Next
1. Spring Cloud Contract Home 3. Spring Cloud Contract FAQ
\ No newline at end of file diff --git a/2.0.x/multi/multi__spring_cloud_contract_verifier_setup.html b/2.0.x/multi/multi__spring_cloud_contract_verifier_setup.html index a989ebb84d..1fa6c15cfb 100644 --- a/2.0.x/multi/multi__spring_cloud_contract_verifier_setup.html +++ b/2.0.x/multi/multi__spring_cloud_contract_verifier_setup.html @@ -616,7 +616,7 @@ requires including an order number followed by an underscore. This will work reg 2_showCart.groovy 3_logout.groovy

Such a tree causes Spring Cloud Contract Verifier to generate WireMock’s scenario with a name of scenario1 and the three following steps:

  1. login marked as Started pointing to…​
  2. showCart marked as Step1 pointing to…​
  3. logout marked as Step2 which will close the scenario.

More details about WireMock scenarios can be found at -http://wiremock.org/docs/stateful-behaviour/

Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.

4.6 Docker Project

We’re publishing a springcloud/spring-cloud-contract Docker image +https://wiremock.org/docs/stateful-behaviour/

Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.

4.6 Docker Project

We’re publishing a springcloud/spring-cloud-contract Docker image that contains a project that will generate tests and execute them in EXPLICIT mode against a running application.

[Tip]Tip

The EXPLICIT mode means that the tests generated from contracts will send real requests and not the mocked ones.

4.6.1 Short intro to Maven, JARs and Binary storage

Since the Docker image can be used by non JVM projects, it’s good to @@ -650,7 +650,7 @@ or Nexus/spring-cloud-contract/build folder (it’s useful for debugging purposes).

It’s enough for you to mount your contracts, pass the environment variables - and the image will:

  • generate the contract tests
  • execute the tests against the provided URL
  • generate the WireMock stubs
  • (optional - turned on by default) publish the stubs to a Artifact Manager

Environment Variables

The Docker image requires some environment variables to point to + and the image will:

  • generate the contract tests
  • execute the tests against the provided URL
  • generate the WireMock stubs
  • (optional - turned on by default) publish the stubs to a Artifact Manager

Environment Variables

The Docker image requires some environment variables to point to your running application, to the Artifact manager instance etc.

  • PROJECT_GROUP - your project’s group id. Defaults to com.example
  • PROJECT_VERSION - your project’s version. Defaults to 0.0.1-SNAPSHOT
  • PROJECT_NAME - artifact id. Defaults to example
  • REPO_WITH_BINARIES_URL - URL of your Artifact Manager. Defaults to http://localhost:8081/artifactory/libs-release-local which is the default URL of Artifactory running locally
  • REPO_WITH_BINARIES_USERNAME - (optional) username when the Artifact Manager is secured
  • REPO_WITH_BINARIES_PASSWORD - (optional) password when the Artifact Manager is secured
  • PUBLISH_ARTIFACTS - if set to true then will publish artifact to binary storage. Defaults to true.

These environment variables are used when contracts lay in an external repository. To enable this feature you must set the EXTERNAL_CONTRACTS_ARTIFACT_ID environment variable.

  • EXTERNAL_CONTRACTS_GROUP_ID - group id of the project with contracts. Defaults to com.example
  • EXTERNAL_CONTRACTS_ARTIFACT_ID- artifact id of the project with contracts.
  • EXTERNAL_CONTRACTS_CLASSIFIER- classifier of the project with contracts. Empty by default
  • EXTERNAL_CONTRACTS_VERSION - version of the project with contracts. Defaults to +, equivalent to picking the latest
  • EXTERNAL_CONTRACTS_REPO_WITH_BINARIES_URL - URL of your Artifact Manager. Defaults to value of REPO_WITH_BINARIES_URL env var. diff --git a/2.0.x/multi/multi__spring_cloud_contract_wiremock.html b/2.0.x/multi/multi__spring_cloud_contract_wiremock.html index cfa75d78be..9d4bf77ec5 100644 --- a/2.0.x/multi/multi__spring_cloud_contract_wiremock.html +++ b/2.0.x/multi/multi__spring_cloud_contract_wiremock.html @@ -1,6 +1,6 @@ - 11. Spring Cloud Contract WireMock
    11. Spring Cloud Contract WireMock
    Prev   Next

    11. Spring Cloud Contract WireMock

    The Spring Cloud Contract WireMock modules let you use WireMock in a + 11. Spring Cloud Contract WireMock

    11. Spring Cloud Contract WireMock
    Prev   Next

    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 @@ -142,7 +142,7 @@ visit WireMock website.

    Currently, the Spring Cloud Contract Verifier supports Tomcat, Jetty, and Undertow as +WireMock website.

    Currently, the Spring Cloud Contract Verifier supports Tomcat, Jetty, and Undertow as Spring Boot embedded servers, and Wiremock itself has "native" support for a particular version of Jetty (currently 9.2). To use the native Jetty, you need to add the native Wiremock dependencies and exclude the Spring Boot container (if there is one).

    11.6 Customization of WireMock configuration

    You can register a bean of org.springframework.cloud.contract.wiremock.WireMockConfigurationCustomizer type diff --git a/2.0.x/multi/multi_contract-dsl.html b/2.0.x/multi/multi_contract-dsl.html index 86bec3df68..01ad48f66f 100644 --- a/2.0.x/multi/multi_contract-dsl.html +++ b/2.0.x/multi/multi_contract-dsl.html @@ -769,7 +769,7 @@ Pattern nonBlank() { } body( email: $(consumer(optional(regex(email()))), producer('abc@abc.com')), - callback_url: $(consumer(regex(hostname())), producer('http://partners.com')) + callback_url: $(consumer(regex(hostname())), producer('https://partners.com')) ) } response { @@ -794,7 +794,7 @@ optional parameters only for the following:

      'abc@abc.com')), - callback_url: $(consumer(regex(hostname())), producer('http://partners.com')) + callback_url: $(consumer(regex(hostname())), producer('https://partners.com')) ) } response { @@ -811,7 +811,7 @@ expression that must be present 0 or more times.

      If you use Spock for, the given: def request = given() .header("Content-Type", "application/json") - .body('''{"email":"abc@abc.com","callback_url":"http://partners.com"}''') + .body('''{"email":"abc@abc.com","callback_url":"https://partners.com"}''') when: def response = given().spec(request) diff --git a/2.0.x/single/spring-cloud-contract.html b/2.0.x/single/spring-cloud-contract.html index eca2c6716e..85bdd9b1d4 100644 --- a/2.0.x/single/spring-cloud-contract.html +++ b/2.0.x/single/spring-cloud-contract.html @@ -6,7 +6,7 @@ distributed system. This project provides support for Consumer Driven Contracts service schemas in Spring applications (for both HTTP and message-based interactions), covering a range of options for writing tests, publishing them as assets, and asserting that a contract is kept by producers and consumers.

    2. Spring Cloud Contract Verifier Introduction

    [Tip]Tip

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

    Spring Cloud Contract Verifier enables Consumer Driven Contract (CDC) development of +(Codearte)

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

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

    • JSON stub definitions to be used by WireMock when doing integration testing on the client code (client tests). Test code must still be written by hand, and test data is @@ -602,7 +602,7 @@ different ranges of values. To enable ranges of values, you can set regular expr matching those values for the consumer side. You can provide the body by means of either a map notation or String with interpolations. Consult the Chapter 8, Contract DSL section for more information. We highly recommend using the map notation!

      [Tip]Tip

      You must understand the map notation in order to set up contracts. Please read the -Groovy docs regarding JSON.

      The previously shown contract is an agreement between two sides that:

      • if an HTTP request is sent with all of

        • a PUT method on the /fraudcheck endpoint,
        • a JSON body with a client.id that matches the regular expression [0-9]{10} and +Groovy docs regarding JSON.

        The previously shown contract is an agreement between two sides that:

        • if an HTTP request is sent with all of

          • a PUT method on the /fraudcheck endpoint,
          • a JSON body with a client.id that matches the regular expression [0-9]{10} and loanAmount equal to 99999,
          • and a Content-Type header with a value of application/vnd.fraud.v1+json,

        • then an HTTP response is sent to the consumer that

          • has status 200,
          • contains a JSON body with the fraudCheckStatus field containing a value FRAUD and the rejectionReason field having value Amount too high,
          • and a Content-Type header with a value of application/vnd.fraud.v1+json.

        Once you are ready to check the API in practice in the integration tests, you need to install the stubs locally.

        Add the Spring Cloud Contract Verifier plugin.

        We can add either a Maven or a Gradle plugin. In this example, you see how to add Maven. @@ -695,7 +695,7 @@ make the name of the base test class. In our case, the contracts were placed und src/test/resources/contracts/fraud. Since you do not have two packages starting from the contracts folder, pick only one, which should be fraud. Add the Base suffix and capitalize fraud. That gives you the FraudBase test class name.

      All the generated tests extend that class. Over there, you can set up your Spring Context -or whatever is necessary. In this case, use Rest Assured MVC to +or whatever is necessary. In this case, use Rest Assured MVC to start the server side FraudDetectionController.

      package com.example.fraud;
 
 import org.junit.Before;
@@ -775,7 +775,7 @@ achieving the same thing by changing the properties.
        repositoryRoot: https://repo.spring.io/libs-snapshot
      That’s it!

    2.5 Dependencies

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

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

    2.6 Additional Links

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

    2.6.1 Spring Cloud Contract video

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

    2.6.2 Readings

    2.7 Samples

    You can find some samples at +constant development.

    2.6.1 Spring Cloud Contract video

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

    2.6.2 Readings

    2.7 Samples

    You can find some samples at samples.

    3. Spring Cloud Contract FAQ

    3.1 Why use Spring Cloud Contract Verifier and not X ?

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

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

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

    No problem. You can write a contract in YAML!

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

    One of the biggest challenges related to stubs is their reusability. Only if they can be vastly used, will they serve their purpose. @@ -843,7 +843,7 @@ for time and UUID are simplified and most likely invalid but we want to keep thi body: "bar" ]) } -}

    [Important]Important

    Please read the Groovy docs related to JSON to understand how to +}

    [Important]Important

    Please read the Groovy docs related to JSON to understand how to properly structure the request / response bodies.

    3.4 How to do Stubs versioning?

    3.4.1 API Versioning

    Let’s try to answer a question what versioning really means. If you’re referring to the API version then there are different approaches.

    • use Hypermedia, links and do not version your API by any means
    • pass versions through headers / urls

    I will not try to answer a question which approach is better. Whatever suit your needs and allows you to generate business value should be picked.

    Let’s assume that you do version your API. In that case you should provide as many contracts as many versions you support. @@ -2036,7 +2036,7 @@ requires including an order number followed by an underscore. This will work reg 2_showCart.groovy 3_logout.groovy

    Such a tree causes Spring Cloud Contract Verifier to generate WireMock’s scenario with a name of scenario1 and the three following steps:

    1. login marked as Started pointing to…​
    2. showCart marked as Step1 pointing to…​
    3. logout marked as Step2 which will close the scenario.

    More details about WireMock scenarios can be found at -http://wiremock.org/docs/stateful-behaviour/

    Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.

    4.6 Docker Project

    We’re publishing a springcloud/spring-cloud-contract Docker image +https://wiremock.org/docs/stateful-behaviour/

    Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.

    4.6 Docker Project

    We’re publishing a springcloud/spring-cloud-contract Docker image that contains a project that will generate tests and execute them in EXPLICIT mode against a running application.

    [Tip]Tip

    The EXPLICIT mode means that the tests generated from contracts will send real requests and not the mocked ones.

    4.6.1 Short intro to Maven, JARs and Binary storage

    Since the Docker image can be used by non JVM projects, it’s good to @@ -2070,7 +2070,7 @@ or Nexus/spring-cloud-contract/build folder (it’s useful for debugging purposes).

    It’s enough for you to mount your contracts, pass the environment variables - and the image will:

    • generate the contract tests
    • execute the tests against the provided URL
    • generate the WireMock stubs
    • (optional - turned on by default) publish the stubs to a Artifact Manager

    Environment Variables

    The Docker image requires some environment variables to point to + and the image will:

    • generate the contract tests
    • execute the tests against the provided URL
    • generate the WireMock stubs
    • (optional - turned on by default) publish the stubs to a Artifact Manager

    Environment Variables

    The Docker image requires some environment variables to point to your running application, to the Artifact manager instance etc.

    • PROJECT_GROUP - your project’s group id. Defaults to com.example
    • PROJECT_VERSION - your project’s version. Defaults to 0.0.1-SNAPSHOT
    • PROJECT_NAME - artifact id. Defaults to example
    • REPO_WITH_BINARIES_URL - URL of your Artifact Manager. Defaults to http://localhost:8081/artifactory/libs-release-local which is the default URL of Artifactory running locally
    • REPO_WITH_BINARIES_USERNAME - (optional) username when the Artifact Manager is secured
    • REPO_WITH_BINARIES_PASSWORD - (optional) password when the Artifact Manager is secured
    • PUBLISH_ARTIFACTS - if set to true then will publish artifact to binary storage. Defaults to true.

    These environment variables are used when contracts lay in an external repository. To enable this feature you must set the EXTERNAL_CONTRACTS_ARTIFACT_ID environment variable.

    • EXTERNAL_CONTRACTS_GROUP_ID - group id of the project with contracts. Defaults to com.example
    • EXTERNAL_CONTRACTS_ARTIFACT_ID- artifact id of the project with contracts.
    • EXTERNAL_CONTRACTS_CLASSIFIER- classifier of the project with contracts. Empty by default
    • EXTERNAL_CONTRACTS_VERSION - version of the project with contracts. Defaults to +, equivalent to picking the latest
    • EXTERNAL_CONTRACTS_REPO_WITH_BINARIES_URL - URL of your Artifact Manager. Defaults to value of REPO_WITH_BINARIES_URL env var. @@ -2617,7 +2617,7 @@ HTTP stubs without the need to download artifacts.

    HTTP Stubs

    Stubs are defined in JSON documents, whose syntax is defined in WireMock documentation

    Example:

    {
+                                  repository

    HTTP Stubs

    Stubs are defined in JSON documents, whose syntax is defined in WireMock documentation

    Example:

    {
     "request": {
         "method": "GET",
         "url": "/ping"
@@ -3001,7 +3001,7 @@ the Stub Runner server. It will be available at port 8750<
 }

    As you can see we want to start a Stub Runner Boot server @EnableStubRunnerServer, enable Eureka client @EnableEurekaClient and we want to have the stub runner feature turned on @AutoConfigureStubRunner.

    Now let’s assume that we want to start this application so that the stubs get automatically registered. We can do it by running the app java -jar ${SYSTEM_PROPS} stub-runner-boot-eureka-example.jar where - ${SYSTEM_PROPS} would contain the following list of properties

    -Dstubrunner.repositoryRoot=https://repo.spring.io/snapshots (1)
+ ${SYSTEM_PROPS} would contain the following list of properties
    -Dstubrunner.repositoryRoot=https://repo.spring.io/snapshot (1)
 -Dstubrunner.cloud.stubbed.discovery.enabled=false (2)
 -Dstubrunner.ids=org.springframework.cloud.contract.verifier.stubs:loanIssuance,org.springframework.cloud.contract.verifier.stubs:fraudDetectionServer,org.springframework.cloud.contract.verifier.stubs:bootService (3)
 -Dstubrunner.idsToServiceIds.fraudDetectionServer=someNameThatShouldMapFraudDetectionServer (4)
@@ -4162,7 +4162,7 @@ Pattern nonBlank() {
 		}
 		body(
 				email: $(consumer(optional(regex(email()))), producer('abc@abc.com')),
-				callback_url: $(consumer(regex(hostname())), producer('http://partners.com'))
+				callback_url: $(consumer(regex(hostname())), producer('https://partners.com'))
 		)
 	}
 	response {
@@ -4187,7 +4187,7 @@ optional parameters only for the following:
      'abc@abc.com')),
-				callback_url: $(consumer(regex(hostname())), producer('http://partners.com'))
+				callback_url: $(consumer(regex(hostname())), producer('https://partners.com'))
 		)
 	}
 	response {
@@ -4204,7 +4204,7 @@ expression that must be present 0 or more times.
      If you use Spock for, the
  given:
   def request = given()
     .header("Content-Type", "application/json")
-    .body('''{"email":"abc@abc.com","callback_url":"http://partners.com"}''')
+    .body('''{"email":"abc@abc.com","callback_url":"https://partners.com"}''')
 
  when:
   def response = given().spec(request)
@@ -6103,7 +6103,7 @@ properties
      * stubrunner.properties.pactbroker.auth.password (system prop)
 
      * STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_PASSWORD (env prop)

    The password passed to contractsRepositoryPassword (maven) or contractRepository.password (gradle)

    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 +

* 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 @@ -6245,7 +6245,7 @@ visit WireMock website.

Currently, the Spring Cloud Contract Verifier supports Tomcat, Jetty, and Undertow as +WireMock website.

Currently, the Spring Cloud Contract Verifier supports Tomcat, Jetty, and Undertow as Spring Boot embedded servers, and Wiremock itself has "native" support for a particular version of Jetty (currently 9.2). To use the native Jetty, you need to add the native Wiremock dependencies and exclude the Spring Boot container (if there is one).

11.6 Customization of WireMock configuration

You can register a bean of org.springframework.cloud.contract.wiremock.WireMockConfigurationCustomizer type diff --git a/2.0.x/spring-cloud-contract.xml b/2.0.x/spring-cloud-contract.xml index 91111832f9..be7debf664 100644 --- a/2.0.x/spring-cloud-contract.xml +++ b/2.0.x/spring-cloud-contract.xml @@ -24,7 +24,7 @@ that a contract is kept by producers and consumers. Spring Cloud Contract Verifier Introduction The Accurest project was initially started by Marcin Grzejszczak and Jakub Kubrynski -(codearte.io) +(Codearte) Spring Cloud Contract Verifier enables Consumer Driven Contract (CDC) development of JVM-based applications. It moves TDD to the level of software architecture. @@ -997,7 +997,7 @@ a map notation or String with interpolations. Consult the section for more information. We highly recommend using the map notation! You must understand the map notation in order to set up contracts. Please read the -Groovy docs regarding JSON. +Groovy docs regarding JSON. The previously shown contract is an agreement between two sides that: @@ -1175,7 +1175,7 @@ the contracts folder, pick only one, which should be fraud. That gives you the FraudBase test class name. All the generated tests extend that class. Over there, you can set up your Spring Context -or whatever is necessary. In this case, use Rest Assured MVC to +or whatever is necessary. In this case, use Rest Assured MVC to start the server side FraudDetectionController. package com.example.fraud; @@ -1303,13 +1303,13 @@ constant development. Slides from Marcin Grzejszczak’s talk about Accurest -Accurest related articles from Marcin Grzejszczak’s blog +Accurest related articles from Marcin Grzejszczak’s blog -Spring Cloud Contract related articles from Marcin Grzejszczak’s blog +Spring Cloud Contract related articles from Marcin Grzejszczak’s blog -Groovy docs regarding JSON +Groovy docs regarding JSON @@ -1452,7 +1452,7 @@ for time and UUID are simplified and most likely invalid but we want to keep thi } } -Please read the Groovy docs related to JSON to understand how to +Please read the Groovy docs related to JSON to understand how to properly structure the request / response bodies. @@ -3448,7 +3448,7 @@ name of scenario1 and the three following steps: More details about WireMock scenarios can be found at -http://wiremock.org/docs/stateful-behaviour/ +https://wiremock.org/docs/stateful-behaviour/ Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.

@@ -3528,7 +3528,7 @@ purposes). execute the tests against the provided URL -generate the WireMock stubs +generate the WireMock stubs (optional - turned on by default) publish the stubs to a Artifact Manager @@ -4445,7 +4445,7 @@ HTTP stubs without the need to download artifacts.
HTTP Stubs -Stubs are defined in JSON documents, whose syntax is defined in WireMock documentation +Stubs are defined in JSON documents, whose syntax is defined in WireMock documentation Example: { "request": { @@ -5056,7 +5056,7 @@ and we want to have the stub runner feature turned on @AutoConfigureStu Now let’s assume that we want to start this application so that the stubs get automatically registered. We can do it by running the app java -jar ${SYSTEM_PROPS} stub-runner-boot-eureka-example.jar where ${SYSTEM_PROPS} would contain the following list of properties --Dstubrunner.repositoryRoot=https://repo.spring.io/snapshots (1) +-Dstubrunner.repositoryRoot=https://repo.spring.io/snapshot (1) -Dstubrunner.cloud.stubbed.discovery.enabled=false (2) -Dstubrunner.ids=org.springframework.cloud.contract.verifier.stubs:loanIssuance,org.springframework.cloud.contract.verifier.stubs:fraudDetectionServer,org.springframework.cloud.contract.verifier.stubs:bootService (3) -Dstubrunner.idsToServiceIds.fraudDetectionServer=someNameThatShouldMapFraudDetectionServer (4) @@ -6886,7 +6886,7 @@ Pattern nonBlank() { } body( email: $(consumer(optional(regex(email()))), producer('abc@abc.com')), - callback_url: $(consumer(regex(hostname())), producer('http://partners.com')) + callback_url: $(consumer(regex(hostname())), producer('https://partners.com')) ) } response { @@ -6928,7 +6928,7 @@ optional parameters only for the following: } body( email: $(consumer(optional(regex(email()))), producer('abc@abc.com')), - callback_url: $(consumer(regex(hostname())), producer('http://partners.com')) + callback_url: $(consumer(regex(hostname())), producer('https://partners.com')) ) } response { @@ -6948,7 +6948,7 @@ expression that must be present 0 or more times. given: def request = given() .header("Content-Type", "application/json") - .body('''{"email":"abc@abc.com","callback_url":"http://partners.com"}''') + .body('''{"email":"abc@abc.com","callback_url":"https://partners.com"}''') when: def response = given().spec(request) @@ -9615,7 +9615,7 @@ properties Spring Cloud Contract WireMock -The Spring Cloud Contract WireMock modules let you use WireMock in a +The Spring Cloud Contract WireMock modules let you use WireMock in a Spring Boot application. Check out the samples for more details. @@ -9798,7 +9798,7 @@ visit https://example.org/< than one stub pattern can be specified, and each one can be a directory (for a recursive list of all ".json"), a fixed filename (as in the example above), or an Ant-style pattern. The JSON format is the normal WireMock format, which you can read about in the -WireMock website. +WireMock website. Currently, the Spring Cloud Contract Verifier supports Tomcat, Jetty, and Undertow as Spring Boot embedded servers, and Wiremock itself has "native" support for a particular version of Jetty (currently 9.2). To use the native Jetty, you need to add the native