diff --git a/2.0.x/multi/multi__contract_dsl.html b/2.0.x/multi/multi__contract_dsl.html index 7a9d31671c..65228fc61b 100644 --- a/2.0.x/multi/multi__contract_dsl.html +++ b/2.0.x/multi/multi__contract_dsl.html @@ -260,7 +260,7 @@ where the value can be a dynamic property (e.g. formParame }, { "matches" : ".*--(.*)\\r\\nContent-Disposition: form-data; name=\\"someBooleanParameter\\"\\r\\n(Content-Type: .*\\r\\n)?(Content-Length: \\\\d+\\r\\n)?\\r\\n(true|false)\\r\\n--\\\\1.*" }, { - "matches" : ".*--(.*)\\r\\nContent-Disposition: form-data; name=\\"file\\"; filename=\\".+\\"\\r\\n(Content-Type: .*\\r\\n)?(Content-Length: \\\\d+\\r\\n)?\\r\\n.+\\r\\n--\\\\1.*" + "matches" : ".*--(.*)\\r\\nContent-Disposition: form-data; name=\\"file\\"; filename=\\"[\\\\S\\\\s]+\\"\\r\\n(Content-Type: .*\\r\\n)?(Content-Length: \\\\d+\\r\\n)?\\r\\n[\\\\S\\\\s]+\\r\\n--\\\\1.*" } ] }, "response" : { @@ -344,8 +344,8 @@ provide the generated string that matches the provided regular expression. For e protected static final Pattern ANY_DATE = Pattern.compile('(\\d\\d\\d\\d)-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])') protected static final Pattern ANY_DATE_TIME = Pattern.compile('([0-9]{4})-(1[0-2]|0[1-9])-(3[01]|0[1-9]|[12][0-9])T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])') protected static final Pattern ANY_TIME = Pattern.compile('(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])') -protected static final Pattern NON_EMPTY = Pattern.compile(/.+/) -protected static final Pattern NON_BLANK = Pattern.compile(/.*(\S+|\R).*|!^\R*$/) +protected static final Pattern NON_EMPTY = Pattern.compile(/[\S\s]+/) +protected static final Pattern NON_BLANK = Pattern.compile(/^\s*\S[\S\s]*/) protected static final Pattern ISO8601_WITH_OFFSET = Pattern.compile(/([0-9]{4})-(1[0-2]|0[1-9])-(3[01]|0[1-9]|[12][0-9])T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])(\.\d{3})?(Z|[+-][01]\d:[0-5]\d)/) protected static Pattern anyOf(String... values){ @@ -556,7 +556,7 @@ It would more or less like this:

// then:
  assertThat(response.statusCode()).isEqualTo(200);

7.5.5 Referencing request from response

The best situation is to provide fixed values but sometimes you need to reference a request in your response. In order to do this you can profit from the fromRequest() method that allows you to reference a bunch -of elements from the HTTP request. You can use the following options:

  • fromRequest().url() - return the request URL
  • fromRequest().query(String key) - return the first query parameter with a given name
  • fromRequest().query(String key, int index) - return the nth query parameter with a given name
  • fromRequest().header(String key) - return the first header with a given name
  • fromRequest().header(String key, int index) - return the nth header with a given name
  • fromRequest().body() - return the full request body
  • fromRequest().body(String jsonPath) - return the element from the request that matches the JSON Path

Let’s take a look at the following contract

Contract contractDsl = Contract.make {
+of elements from the HTTP request. You can use the following options:

  • fromRequest().url() - return the request URL and query parameters
  • fromRequest().query(String key) - return the first query parameter with a given name
  • fromRequest().query(String key, int index) - return the nth query parameter with a given name
  • fromRequest().path() - return the full path
  • fromRequest().path(int index) - return the nth path element
  • fromRequest().header(String key) - return the first header with a given name
  • fromRequest().header(String key, int index) - return the nth header with a given name
  • fromRequest().body() - return the full request body
  • fromRequest().body(String jsonPath) - return the element from the request that matches the JSON Path

Let’s take a look at the following contract

Contract contractDsl = Contract.make {
 	request {
 		method 'GET'
 		url('/api/v1/xxxx') {
@@ -578,6 +578,8 @@ of elements from the HTTP request. You can use the following options:

1), param: fromRequest().query("foo"), paramIndex: fromRequest().query("foo", 1), authorization: fromRequest().header("Authorization"), @@ -605,15 +607,17 @@ of elements from the HTTP request. You can use the following options:

"Authorization")).isEqualTo("foo secret bar"); // and: DocumentContext parsedJson = JsonPath.parse(response.getBody().asString()); - assertThatJson(parsedJson).field("url").isEqualTo("/api/v1/xxxx"); - assertThatJson(parsedJson).field("fullBody").isEqualTo("{\"foo\":\"bar\",\"baz\":5}"); - assertThatJson(parsedJson).field("paramIndex").isEqualTo("bar2"); - assertThatJson(parsedJson).field("responseFoo").isEqualTo("bar"); - assertThatJson(parsedJson).field("authorization2").isEqualTo("secret2"); - assertThatJson(parsedJson).field("responseBaz").isEqualTo(5); - assertThatJson(parsedJson).field("responseBaz2").isEqualTo("Bla bla bar bla bla"); - assertThatJson(parsedJson).field("param").isEqualTo("bar"); - assertThatJson(parsedJson).field("authorization").isEqualTo("secret");

As you can see elements from the request have been properly referenced in the response.

The generated WireMock stub will look more or less like this:

{
+ assertThatJson(parsedJson).field("['fullBody']").isEqualTo("{\"foo\":\"bar\",\"baz\":5}");
+ assertThatJson(parsedJson).field("['authorization']").isEqualTo("secret");
+ assertThatJson(parsedJson).field("['authorization2']").isEqualTo("secret2");
+ assertThatJson(parsedJson).field("['path']").isEqualTo("/api/v1/xxxx");
+ assertThatJson(parsedJson).field("['param']").isEqualTo("bar");
+ assertThatJson(parsedJson).field("['paramIndex']").isEqualTo("bar2");
+ assertThatJson(parsedJson).field("['pathIndex']").isEqualTo("v1");
+ assertThatJson(parsedJson).field("['responseBaz']").isEqualTo(5);
+ assertThatJson(parsedJson).field("['responseFoo']").isEqualTo("bar");
+ assertThatJson(parsedJson).field("['url']").isEqualTo("/api/v1/xxxx?foo=bar&foo=bar2");
+ assertThatJson(parsedJson).field("['responseBaz2']").isEqualTo("Bla bla bar bla bla");

As you can see elements from the request have been properly referenced in the response.

The generated WireMock stub will look more or less like this:

{
   "request" : {
     "urlPath" : "/api/v1/xxxx",
     "method" : "POST",
@@ -628,22 +632,24 @@ of elements from the HTTP request. You can use the following options:

} }, "bodyPatterns" : [ { - "matchesJsonPath" : "$[?(@.baz == 5)]" + "matchesJsonPath" : "$[?(@.['baz'] == 5)]" }, { - "matchesJsonPath" : "$[?(@.foo == 'bar')]" + "matchesJsonPath" : "$[?(@.['foo'] == 'bar')]" } ] }, "response" : { "status" : 200, - "body" : "{\"url\":\"{{{request.url}}}\",\"param\":\"{{{request.query.foo.[0]}}}\",\"paramIndex\":\"{{{request.query.foo.[1]}}}\",\"authorization\":\"{{{request.headers.Authorization.[0]}}}\",\"authorization2\":\"{{{request.headers.Authorization.[1]}}}\",\"fullBody\":\"{{{escapejsonbody}}}\",\"responseFoo\":\"{{{jsonpath this '$.foo'}}}\",\"responseBaz\":{{{jsonpath this '$.baz'}}} ,\"responseBaz2\":\"Bla bla {{{jsonpath this '$.foo'}}} bla bla\"}", + "body" : "{\"authorization\":\"{{{request.headers.Authorization.[0]}}}\",\"path\":\"{{{request.path}}}\",\"responseBaz\":{{{jsonpath this '$.baz'}}} ,\"param\":\"{{{request.query.foo.[0]}}}\",\"pathIndex\":\"{{{request.path.[1]}}}\",\"responseBaz2\":\"Bla bla {{{jsonpath this '$.foo'}}} bla bla\",\"responseFoo\":\"{{{jsonpath this '$.foo'}}}\",\"authorization2\":\"{{{request.headers.Authorization.[1]}}}\",\"fullBody\":\"{{{escapejsonbody}}}\",\"url\":\"{{{request.url}}}\",\"paramIndex\":\"{{{request.query.foo.[1]}}}\"}", "headers" : { - "Authorization" : "{{{request.headers.Authorization.[0]}}}" + "Authorization" : "{{{request.headers.Authorization.[0]}}};foo" }, "transformers" : [ "response-template" ] } }

So sending a request as the one presented in the request part of the contract will lead in sending the following response body

{
   "url" : "/api/v1/xxxx?foo=bar&foo=bar2",
+  "path" : "/api/v1/xxxx",
+  "pathIndex" : "v1",
   "param" : "bar",
   "paramIndex" : "bar2",
   "authorization" : "secret",
@@ -876,7 +882,7 @@ that we took the method name and passed the proper JSON path as a parameter to i
   },
   "response" : {
     "status" : 200,
-    "body" : "{\\"duck\\":123,\\"alpha\\":\\"abc\\",\\"number\\":123,\\"aBoolean\\":true,\\"date\\":\\"2017-01-01\\",\\"dateTime\\":\\"2017-01-01T01:23:45\\",\\"time\\":\\"01:02:34\\",\\"valueWithoutAMatcher\\":\\"foo\\",\\"valueWithTypeMatch\\":\\"string\\",\\"valueWithMin\\":[1,2,3],\\"valueWithMax\\":[1,2,3],\\"valueWithMinMax\\":[1,2,3]}",
+    "body" : "{\\"date\\":\\"2017-01-01\\",\\"dateTime\\":\\"2017-01-01T01:23:45\\",\\"number\\":123,\\"aBoolean\\":true,\\"duck\\":123,\\"alpha\\":\\"abc\\",\\"valueWithMin\\":[1,2,3],\\"time\\":\\"01:02:34\\",\\"valueWithTypeMatch\\":\\"string\\",\\"valueWithMax\\":[1,2,3],\\"valueWithMinMax\\":[1,2,3],\\"valueWithoutAMatcher\\":\\"foo\\"}",
     "headers" : {
       "Content-Type" : "application/json"
     }
diff --git a/2.0.x/multi/multi__migrations.html b/2.0.x/multi/multi__migrations.html
index cf9ef4a1d1..1ad50d32d7 100644
--- a/2.0.x/multi/multi__migrations.html
+++ b/2.0.x/multi/multi__migrations.html
@@ -80,4 +80,6 @@ snippet above.

Maven.  have to implement that method too. It should return a String representing all mappings available in a single HttpServerStub. Related to issue 355.

11.2.2 New packages for generated tests

The flow for setting the generated tests package name will look like this:

  • pick basePackageForTests
  • if basePackageForTests wasn’t set pick the package from baseClassForTests
  • if baseClassForTests wasn’t set pick packageWithBaseClasses
  • if nothing got set pick the default org.springframework.cloud.contract.verifier.tests value

Related to -issue 260.

\ No newline at end of file +issue 260.

11.2.3 New methods in TemplateProcessor

In order to add support for fromRequest.path some methods had to be added to the +TemplateProcessor interface.

Related to +issue 388.

\ No newline at end of file diff --git a/2.0.x/multi/multi_spring-cloud-contract.html b/2.0.x/multi/multi_spring-cloud-contract.html index 82ede2712f..d8324ea9d7 100644 --- a/2.0.x/multi/multi_spring-cloud-contract.html +++ b/2.0.x/multi/multi_spring-cloud-contract.html @@ -1,3 +1,3 @@ - Spring Cloud Contract

Spring Cloud Contract


Table of Contents

1. Spring Cloud Contract
2. Spring Cloud Contract Verifier Introduction
2.1. Why?
2.1.1. Testing issues
2.2. Purposes
2.3. How
2.3.1. Define the contract
2.3.2. Client Side
2.3.3. Server Side
2.4. Step by step guide to CDC
2.4.1. Technical note
2.4.2. Consumer side (Loan Issuance)
2.4.3. Producer side (Fraud Detection server)
2.4.4. Consumer side (Loan Issuance) final step
2.5. Dependencies
2.6. Additional links
2.6.1. Spring Cloud Contract video
2.6.2. Readings
2.7. Samples
3. Spring Cloud Contract Verifier Setup
3.1. Gradle Project
3.1.1. Prerequisites
3.1.2. Add gradle plugin with dependencies
3.1.3. Gradle and Rest Assured 2.0
3.1.4. Snapshot versions for Gradle
3.1.5. Add stubs
3.1.6. Run plugin
3.1.7. Default setup
3.1.8. Configure plugin
3.1.9. Configuration options
3.1.10. Single base class for all tests
3.1.11. Different base classes for contracts
3.1.12. Invoking generated tests
3.1.13. Spring Cloud Contract Verifier on consumer side
3.2. Using in your Maven project
3.2.1. Add maven plugin
3.2.2. Maven and Rest Assured 2.0
3.2.3. Snapshot versions for Maven
3.2.4. Add stubs
3.2.5. Run plugin
3.2.6. Configure plugin
3.2.7. Important configuration options
3.2.8. Single base class for all tests
3.2.9. Different base classes for contracts
3.2.10. Invoking generated tests
3.2.11. FAQ with Maven Plugin
3.2.12. Maven Plugin and STS
3.2.13. Spring Cloud Contract Verifier on consumer side
3.3. Scenarios
3.4. Stubs and transitive dependencies
4. Spring Cloud Contract Verifier Messaging
4.1. Integrations
4.2. Manual Integration Testing
4.3. Publisher side test generation
4.3.1. Scenario 1 (no input message)
4.3.2. Scenario 2 (output triggered by input)
4.3.3. Scenario 3 (no output message)
4.4. Consumer Stub Side generation
5. Spring Cloud Contract Stub Runner
5.1. Snapshot versions
5.2. Publishing stubs as JARs
5.3. Stub Runner Core
5.3.1. Retrieving stubs
Stub downloading
Classpath scanning
5.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
5.4. Stub Runner JUnit Rule
5.4.1. Maven settings
5.4.2. Providing fixed ports
5.4.3. Fluent API
5.4.4. Stub Runner with Spring
5.5. Stub Runner Spring Cloud
5.5.1. Stubbing Service Discovery
Test profiles and service discovery
5.5.2. Additional Configuration
5.6. Stub Runner Boot Application
5.6.1. How to use it?
Stub Runner Server
Spring Cloud CLI
5.6.2. Endpoints
HTTP
Messaging
5.6.3. Example
5.6.4. Stub Runner Boot with Service Discovery
5.7. Stubs Per Consumer
5.8. Common
5.8.1. Common properties for JUnit and Spring
5.8.2. Stub runner stubs ids
6. Stub Runner for Messaging
6.1. Stub triggering
6.1.1. Trigger by label
6.1.2. Trigger by group and artifact ids
6.1.3. Trigger by artifact ids
6.1.4. Trigger all messages
6.2. Stub Runner Camel
6.2.1. Adding it to the project
6.2.2. Disabling the functionality
6.2.3. Examples
Stubs structure
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.3. Stub Runner Integration
6.3.1. Adding it to the project
6.3.2. Disabling the functionality
6.3.3. Examples
Stubs structure
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.4. Stub Runner Stream
6.4.1. Adding it to the project
6.4.2. Disabling the functionality
6.4.3. Examples
Stubs structure
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.5. Stub Runner Spring AMQP
6.5.1. Adding it to the project
6.5.2. Examples
Stubs structure
Triggering the message
Spring AMQP Test Configuration
7. Contract DSL
7.1. Limitations
7.2. Common Top-Level elements
7.2.1. Description
7.2.2. Name
7.2.3. Ignoring contracts
7.2.4. Passing values from files
7.2.5. HTTP Top-Level Elements
7.3. Request
7.4. Response
7.5. Dynamic properties
7.5.1. Dynamic properties inside the body
7.5.2. Regular expressions
7.5.3. Passing optional parameters
7.5.4. Executing custom methods on server side
7.5.5. Referencing request from response
7.5.6. Dynamic properties in matchers sections
7.6. JAX-RS support
7.7. Async support
7.8. Working with Context Paths
7.9. Messaging Top-Level Elements
7.9.1. Output triggered by a method
7.9.2. Output triggered by a message
7.9.3. Consumer / Producer
7.10. Multiple contracts in one file
8. Customization
8.1. Extending the DSL
8.1.1. Common JAR
8.1.2. Adding the dependency to project
8.1.3. Test dependency in project’s dependencies
8.1.4. Test dependency in plugin’s dependencies
8.1.5. Referencing classes in DSLs
9. Pluggable architecture
9.1. Custom contract converter
9.1.1. Pact converter
9.1.2. Pact contract
9.1.3. Pact for producers
9.1.4. Pact for consumers
9.2. Custom test generator
9.3. Custom stub generator
9.4. Custom Stub Runner
9.5. Custom Stub Downloader
10. Spring Cloud Contract WireMock
10.1. Registering Stubs Automatically
10.2. Using Files to Specify the Stub Bodies
10.3. Alternative: Using JUnit Rules
10.4. Relaxed SSL Validation for Rest Template
10.5. WireMock and Spring MVC Mocks
10.6. Generating Stubs using RestDocs
10.7. Generating Contracts using RestDocs
11. Migrations
11.1. 1.0.x → 1.1.x
11.1.1. New structure of generated stubs
11.2. 1.1.x → 1.2.x
11.2.1. Custom HttpServerStub
11.2.2. New packages for generated tests
12. Links
\ No newline at end of file + Spring Cloud Contract

Spring Cloud Contract


Table of Contents

1. Spring Cloud Contract
2. Spring Cloud Contract Verifier Introduction
2.1. Why?
2.1.1. Testing issues
2.2. Purposes
2.3. How
2.3.1. Define the contract
2.3.2. Client Side
2.3.3. Server Side
2.4. Step by step guide to CDC
2.4.1. Technical note
2.4.2. Consumer side (Loan Issuance)
2.4.3. Producer side (Fraud Detection server)
2.4.4. Consumer side (Loan Issuance) final step
2.5. Dependencies
2.6. Additional links
2.6.1. Spring Cloud Contract video
2.6.2. Readings
2.7. Samples
3. Spring Cloud Contract Verifier Setup
3.1. Gradle Project
3.1.1. Prerequisites
3.1.2. Add gradle plugin with dependencies
3.1.3. Gradle and Rest Assured 2.0
3.1.4. Snapshot versions for Gradle
3.1.5. Add stubs
3.1.6. Run plugin
3.1.7. Default setup
3.1.8. Configure plugin
3.1.9. Configuration options
3.1.10. Single base class for all tests
3.1.11. Different base classes for contracts
3.1.12. Invoking generated tests
3.1.13. Spring Cloud Contract Verifier on consumer side
3.2. Using in your Maven project
3.2.1. Add maven plugin
3.2.2. Maven and Rest Assured 2.0
3.2.3. Snapshot versions for Maven
3.2.4. Add stubs
3.2.5. Run plugin
3.2.6. Configure plugin
3.2.7. Important configuration options
3.2.8. Single base class for all tests
3.2.9. Different base classes for contracts
3.2.10. Invoking generated tests
3.2.11. FAQ with Maven Plugin
3.2.12. Maven Plugin and STS
3.2.13. Spring Cloud Contract Verifier on consumer side
3.3. Scenarios
3.4. Stubs and transitive dependencies
4. Spring Cloud Contract Verifier Messaging
4.1. Integrations
4.2. Manual Integration Testing
4.3. Publisher side test generation
4.3.1. Scenario 1 (no input message)
4.3.2. Scenario 2 (output triggered by input)
4.3.3. Scenario 3 (no output message)
4.4. Consumer Stub Side generation
5. Spring Cloud Contract Stub Runner
5.1. Snapshot versions
5.2. Publishing stubs as JARs
5.3. Stub Runner Core
5.3.1. Retrieving stubs
Stub downloading
Classpath scanning
5.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
5.4. Stub Runner JUnit Rule
5.4.1. Maven settings
5.4.2. Providing fixed ports
5.4.3. Fluent API
5.4.4. Stub Runner with Spring
5.5. Stub Runner Spring Cloud
5.5.1. Stubbing Service Discovery
Test profiles and service discovery
5.5.2. Additional Configuration
5.6. Stub Runner Boot Application
5.6.1. How to use it?
Stub Runner Server
Spring Cloud CLI
5.6.2. Endpoints
HTTP
Messaging
5.6.3. Example
5.6.4. Stub Runner Boot with Service Discovery
5.7. Stubs Per Consumer
5.8. Common
5.8.1. Common properties for JUnit and Spring
5.8.2. Stub runner stubs ids
6. Stub Runner for Messaging
6.1. Stub triggering
6.1.1. Trigger by label
6.1.2. Trigger by group and artifact ids
6.1.3. Trigger by artifact ids
6.1.4. Trigger all messages
6.2. Stub Runner Camel
6.2.1. Adding it to the project
6.2.2. Disabling the functionality
6.2.3. Examples
Stubs structure
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.3. Stub Runner Integration
6.3.1. Adding it to the project
6.3.2. Disabling the functionality
6.3.3. Examples
Stubs structure
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.4. Stub Runner Stream
6.4.1. Adding it to the project
6.4.2. Disabling the functionality
6.4.3. Examples
Stubs structure
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.5. Stub Runner Spring AMQP
6.5.1. Adding it to the project
6.5.2. Examples
Stubs structure
Triggering the message
Spring AMQP Test Configuration
7. Contract DSL
7.1. Limitations
7.2. Common Top-Level elements
7.2.1. Description
7.2.2. Name
7.2.3. Ignoring contracts
7.2.4. Passing values from files
7.2.5. HTTP Top-Level Elements
7.3. Request
7.4. Response
7.5. Dynamic properties
7.5.1. Dynamic properties inside the body
7.5.2. Regular expressions
7.5.3. Passing optional parameters
7.5.4. Executing custom methods on server side
7.5.5. Referencing request from response
7.5.6. Dynamic properties in matchers sections
7.6. JAX-RS support
7.7. Async support
7.8. Working with Context Paths
7.9. Messaging Top-Level Elements
7.9.1. Output triggered by a method
7.9.2. Output triggered by a message
7.9.3. Consumer / Producer
7.10. Multiple contracts in one file
8. Customization
8.1. Extending the DSL
8.1.1. Common JAR
8.1.2. Adding the dependency to project
8.1.3. Test dependency in project’s dependencies
8.1.4. Test dependency in plugin’s dependencies
8.1.5. Referencing classes in DSLs
9. Pluggable architecture
9.1. Custom contract converter
9.1.1. Pact converter
9.1.2. Pact contract
9.1.3. Pact for producers
9.1.4. Pact for consumers
9.2. Custom test generator
9.3. Custom stub generator
9.4. Custom Stub Runner
9.5. Custom Stub Downloader
10. Spring Cloud Contract WireMock
10.1. Registering Stubs Automatically
10.2. Using Files to Specify the Stub Bodies
10.3. Alternative: Using JUnit Rules
10.4. Relaxed SSL Validation for Rest Template
10.5. WireMock and Spring MVC Mocks
10.6. Generating Stubs using RestDocs
10.7. Generating Contracts using RestDocs
11. Migrations
11.1. 1.0.x → 1.1.x
11.1.1. New structure of generated stubs
11.2. 1.1.x → 1.2.x
11.2.1. Custom HttpServerStub
11.2.2. New packages for generated tests
11.2.3. New methods in TemplateProcessor
12. Links
\ No newline at end of file diff --git a/2.0.x/single/spring-cloud-contract.html b/2.0.x/single/spring-cloud-contract.html index 8ff4563754..9c3717d4e0 100644 --- a/2.0.x/single/spring-cloud-contract.html +++ b/2.0.x/single/spring-cloud-contract.html @@ -1,6 +1,6 @@ - Spring Cloud Contract

Spring Cloud Contract


Table of Contents

1. Spring Cloud Contract
2. Spring Cloud Contract Verifier Introduction
2.1. Why?
2.1.1. Testing issues
2.2. Purposes
2.3. How
2.3.1. Define the contract
2.3.2. Client Side
2.3.3. Server Side
2.4. Step by step guide to CDC
2.4.1. Technical note
2.4.2. Consumer side (Loan Issuance)
2.4.3. Producer side (Fraud Detection server)
2.4.4. Consumer side (Loan Issuance) final step
2.5. Dependencies
2.6. Additional links
2.6.1. Spring Cloud Contract video
2.6.2. Readings
2.7. Samples
3. Spring Cloud Contract Verifier Setup
3.1. Gradle Project
3.1.1. Prerequisites
3.1.2. Add gradle plugin with dependencies
3.1.3. Gradle and Rest Assured 2.0
3.1.4. Snapshot versions for Gradle
3.1.5. Add stubs
3.1.6. Run plugin
3.1.7. Default setup
3.1.8. Configure plugin
3.1.9. Configuration options
3.1.10. Single base class for all tests
3.1.11. Different base classes for contracts
3.1.12. Invoking generated tests
3.1.13. Spring Cloud Contract Verifier on consumer side
3.2. Using in your Maven project
3.2.1. Add maven plugin
3.2.2. Maven and Rest Assured 2.0
3.2.3. Snapshot versions for Maven
3.2.4. Add stubs
3.2.5. Run plugin
3.2.6. Configure plugin
3.2.7. Important configuration options
3.2.8. Single base class for all tests
3.2.9. Different base classes for contracts
3.2.10. Invoking generated tests
3.2.11. FAQ with Maven Plugin
3.2.12. Maven Plugin and STS
3.2.13. Spring Cloud Contract Verifier on consumer side
3.3. Scenarios
3.4. Stubs and transitive dependencies
4. Spring Cloud Contract Verifier Messaging
4.1. Integrations
4.2. Manual Integration Testing
4.3. Publisher side test generation
4.3.1. Scenario 1 (no input message)
4.3.2. Scenario 2 (output triggered by input)
4.3.3. Scenario 3 (no output message)
4.4. Consumer Stub Side generation
5. Spring Cloud Contract Stub Runner
5.1. Snapshot versions
5.2. Publishing stubs as JARs
5.3. Stub Runner Core
5.3.1. Retrieving stubs
Stub downloading
Classpath scanning
5.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
5.4. Stub Runner JUnit Rule
5.4.1. Maven settings
5.4.2. Providing fixed ports
5.4.3. Fluent API
5.4.4. Stub Runner with Spring
5.5. Stub Runner Spring Cloud
5.5.1. Stubbing Service Discovery
Test profiles and service discovery
5.5.2. Additional Configuration
5.6. Stub Runner Boot Application
5.6.1. How to use it?
Stub Runner Server
Spring Cloud CLI
5.6.2. Endpoints
HTTP
Messaging
5.6.3. Example
5.6.4. Stub Runner Boot with Service Discovery
5.7. Stubs Per Consumer
5.8. Common
5.8.1. Common properties for JUnit and Spring
5.8.2. Stub runner stubs ids
6. Stub Runner for Messaging
6.1. Stub triggering
6.1.1. Trigger by label
6.1.2. Trigger by group and artifact ids
6.1.3. Trigger by artifact ids
6.1.4. Trigger all messages
6.2. Stub Runner Camel
6.2.1. Adding it to the project
6.2.2. Disabling the functionality
6.2.3. Examples
Stubs structure
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.3. Stub Runner Integration
6.3.1. Adding it to the project
6.3.2. Disabling the functionality
6.3.3. Examples
Stubs structure
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.4. Stub Runner Stream
6.4.1. Adding it to the project
6.4.2. Disabling the functionality
6.4.3. Examples
Stubs structure
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.5. Stub Runner Spring AMQP
6.5.1. Adding it to the project
6.5.2. Examples
Stubs structure
Triggering the message
Spring AMQP Test Configuration
7. Contract DSL
7.1. Limitations
7.2. Common Top-Level elements
7.2.1. Description
7.2.2. Name
7.2.3. Ignoring contracts
7.2.4. Passing values from files
7.2.5. HTTP Top-Level Elements
7.3. Request
7.4. Response
7.5. Dynamic properties
7.5.1. Dynamic properties inside the body
7.5.2. Regular expressions
7.5.3. Passing optional parameters
7.5.4. Executing custom methods on server side
7.5.5. Referencing request from response
7.5.6. Dynamic properties in matchers sections
7.6. JAX-RS support
7.7. Async support
7.8. Working with Context Paths
7.9. Messaging Top-Level Elements
7.9.1. Output triggered by a method
7.9.2. Output triggered by a message
7.9.3. Consumer / Producer
7.10. Multiple contracts in one file
8. Customization
8.1. Extending the DSL
8.1.1. Common JAR
8.1.2. Adding the dependency to project
8.1.3. Test dependency in project’s dependencies
8.1.4. Test dependency in plugin’s dependencies
8.1.5. Referencing classes in DSLs
9. Pluggable architecture
9.1. Custom contract converter
9.1.1. Pact converter
9.1.2. Pact contract
9.1.3. Pact for producers
9.1.4. Pact for consumers
9.2. Custom test generator
9.3. Custom stub generator
9.4. Custom Stub Runner
9.5. Custom Stub Downloader
10. Spring Cloud Contract WireMock
10.1. Registering Stubs Automatically
10.2. Using Files to Specify the Stub Bodies
10.3. Alternative: Using JUnit Rules
10.4. Relaxed SSL Validation for Rest Template
10.5. WireMock and Spring MVC Mocks
10.6. Generating Stubs using RestDocs
10.7. Generating Contracts using RestDocs
11. Migrations
11.1. 1.0.x → 1.1.x
11.1.1. New structure of generated stubs
11.2. 1.1.x → 1.2.x
11.2.1. Custom HttpServerStub
11.2.2. New packages for generated tests
12. Links

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

Spring Cloud Contract


Table of Contents

1. Spring Cloud Contract
2. Spring Cloud Contract Verifier Introduction
2.1. Why?
2.1.1. Testing issues
2.2. Purposes
2.3. How
2.3.1. Define the contract
2.3.2. Client Side
2.3.3. Server Side
2.4. Step by step guide to CDC
2.4.1. Technical note
2.4.2. Consumer side (Loan Issuance)
2.4.3. Producer side (Fraud Detection server)
2.4.4. Consumer side (Loan Issuance) final step
2.5. Dependencies
2.6. Additional links
2.6.1. Spring Cloud Contract video
2.6.2. Readings
2.7. Samples
3. Spring Cloud Contract Verifier Setup
3.1. Gradle Project
3.1.1. Prerequisites
3.1.2. Add gradle plugin with dependencies
3.1.3. Gradle and Rest Assured 2.0
3.1.4. Snapshot versions for Gradle
3.1.5. Add stubs
3.1.6. Run plugin
3.1.7. Default setup
3.1.8. Configure plugin
3.1.9. Configuration options
3.1.10. Single base class for all tests
3.1.11. Different base classes for contracts
3.1.12. Invoking generated tests
3.1.13. Spring Cloud Contract Verifier on consumer side
3.2. Using in your Maven project
3.2.1. Add maven plugin
3.2.2. Maven and Rest Assured 2.0
3.2.3. Snapshot versions for Maven
3.2.4. Add stubs
3.2.5. Run plugin
3.2.6. Configure plugin
3.2.7. Important configuration options
3.2.8. Single base class for all tests
3.2.9. Different base classes for contracts
3.2.10. Invoking generated tests
3.2.11. FAQ with Maven Plugin
3.2.12. Maven Plugin and STS
3.2.13. Spring Cloud Contract Verifier on consumer side
3.3. Scenarios
3.4. Stubs and transitive dependencies
4. Spring Cloud Contract Verifier Messaging
4.1. Integrations
4.2. Manual Integration Testing
4.3. Publisher side test generation
4.3.1. Scenario 1 (no input message)
4.3.2. Scenario 2 (output triggered by input)
4.3.3. Scenario 3 (no output message)
4.4. Consumer Stub Side generation
5. Spring Cloud Contract Stub Runner
5.1. Snapshot versions
5.2. Publishing stubs as JARs
5.3. Stub Runner Core
5.3.1. Retrieving stubs
Stub downloading
Classpath scanning
5.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
5.4. Stub Runner JUnit Rule
5.4.1. Maven settings
5.4.2. Providing fixed ports
5.4.3. Fluent API
5.4.4. Stub Runner with Spring
5.5. Stub Runner Spring Cloud
5.5.1. Stubbing Service Discovery
Test profiles and service discovery
5.5.2. Additional Configuration
5.6. Stub Runner Boot Application
5.6.1. How to use it?
Stub Runner Server
Spring Cloud CLI
5.6.2. Endpoints
HTTP
Messaging
5.6.3. Example
5.6.4. Stub Runner Boot with Service Discovery
5.7. Stubs Per Consumer
5.8. Common
5.8.1. Common properties for JUnit and Spring
5.8.2. Stub runner stubs ids
6. Stub Runner for Messaging
6.1. Stub triggering
6.1.1. Trigger by label
6.1.2. Trigger by group and artifact ids
6.1.3. Trigger by artifact ids
6.1.4. Trigger all messages
6.2. Stub Runner Camel
6.2.1. Adding it to the project
6.2.2. Disabling the functionality
6.2.3. Examples
Stubs structure
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.3. Stub Runner Integration
6.3.1. Adding it to the project
6.3.2. Disabling the functionality
6.3.3. Examples
Stubs structure
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.4. Stub Runner Stream
6.4.1. Adding it to the project
6.4.2. Disabling the functionality
6.4.3. Examples
Stubs structure
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.5. Stub Runner Spring AMQP
6.5.1. Adding it to the project
6.5.2. Examples
Stubs structure
Triggering the message
Spring AMQP Test Configuration
7. Contract DSL
7.1. Limitations
7.2. Common Top-Level elements
7.2.1. Description
7.2.2. Name
7.2.3. Ignoring contracts
7.2.4. Passing values from files
7.2.5. HTTP Top-Level Elements
7.3. Request
7.4. Response
7.5. Dynamic properties
7.5.1. Dynamic properties inside the body
7.5.2. Regular expressions
7.5.3. Passing optional parameters
7.5.4. Executing custom methods on server side
7.5.5. Referencing request from response
7.5.6. Dynamic properties in matchers sections
7.6. JAX-RS support
7.7. Async support
7.8. Working with Context Paths
7.9. Messaging Top-Level Elements
7.9.1. Output triggered by a method
7.9.2. Output triggered by a message
7.9.3. Consumer / Producer
7.10. Multiple contracts in one file
8. Customization
8.1. Extending the DSL
8.1.1. Common JAR
8.1.2. Adding the dependency to project
8.1.3. Test dependency in project’s dependencies
8.1.4. Test dependency in plugin’s dependencies
8.1.5. Referencing classes in DSLs
9. Pluggable architecture
9.1. Custom contract converter
9.1.1. Pact converter
9.1.2. Pact contract
9.1.3. Pact for producers
9.1.4. Pact for consumers
9.2. Custom test generator
9.3. Custom stub generator
9.4. Custom Stub Runner
9.5. Custom Stub Downloader
10. Spring Cloud Contract WireMock
10.1. Registering Stubs Automatically
10.2. Using Files to Specify the Stub Bodies
10.3. Alternative: Using JUnit Rules
10.4. Relaxed SSL Validation for Rest Template
10.5. WireMock and Spring MVC Mocks
10.6. Generating Stubs using RestDocs
10.7. Generating Contracts using RestDocs
11. Migrations
11.1. 1.0.x → 1.1.x
11.1.1. New structure of generated stubs
11.2. 1.1.x → 1.2.x
11.2.1. Custom HttpServerStub
11.2.2. New packages for generated tests
11.2.3. New methods in TemplateProcessor
12. Links

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

2.0.0.BUILD-SNAPSHOT

1. Spring Cloud Contract

What you always need is confidence in pushing new features into a new application or service in a distributed system. This project provides support for Consumer Driven Contracts and service schemas in Spring applications, covering a range of options for writing tests, publishing them as assets, asserting that a contract is kept by producers @@ -2322,7 +2322,7 @@ where the value can be a dynamic property (e.g. formParame }, { "matches" : ".*--(.*)\\r\\nContent-Disposition: form-data; name=\\"someBooleanParameter\\"\\r\\n(Content-Type: .*\\r\\n)?(Content-Length: \\\\d+\\r\\n)?\\r\\n(true|false)\\r\\n--\\\\1.*" }, { - "matches" : ".*--(.*)\\r\\nContent-Disposition: form-data; name=\\"file\\"; filename=\\".+\\"\\r\\n(Content-Type: .*\\r\\n)?(Content-Length: \\\\d+\\r\\n)?\\r\\n.+\\r\\n--\\\\1.*" + "matches" : ".*--(.*)\\r\\nContent-Disposition: form-data; name=\\"file\\"; filename=\\"[\\\\S\\\\s]+\\"\\r\\n(Content-Type: .*\\r\\n)?(Content-Length: \\\\d+\\r\\n)?\\r\\n[\\\\S\\\\s]+\\r\\n--\\\\1.*" } ] }, "response" : { @@ -2406,8 +2406,8 @@ provide the generated string that matches the provided regular expression. For e protected static final Pattern ANY_DATE = Pattern.compile('(\\d\\d\\d\\d)-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])') protected static final Pattern ANY_DATE_TIME = Pattern.compile('([0-9]{4})-(1[0-2]|0[1-9])-(3[01]|0[1-9]|[12][0-9])T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])') protected static final Pattern ANY_TIME = Pattern.compile('(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])') -protected static final Pattern NON_EMPTY = Pattern.compile(/.+/) -protected static final Pattern NON_BLANK = Pattern.compile(/.*(\S+|\R).*|!^\R*$/) +protected static final Pattern NON_EMPTY = Pattern.compile(/[\S\s]+/) +protected static final Pattern NON_BLANK = Pattern.compile(/^\s*\S[\S\s]*/) protected static final Pattern ISO8601_WITH_OFFSET = Pattern.compile(/([0-9]{4})-(1[0-2]|0[1-9])-(3[01]|0[1-9]|[12][0-9])T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])(\.\d{3})?(Z|[+-][01]\d:[0-5]\d)/) protected static Pattern anyOf(String... values){ @@ -2618,7 +2618,7 @@ It would more or less like this:

// then:
  assertThat(response.statusCode()).isEqualTo(200);

7.5.5 Referencing request from response

The best situation is to provide fixed values but sometimes you need to reference a request in your response. In order to do this you can profit from the fromRequest() method that allows you to reference a bunch -of elements from the HTTP request. You can use the following options:

  • fromRequest().url() - return the request URL
  • fromRequest().query(String key) - return the first query parameter with a given name
  • fromRequest().query(String key, int index) - return the nth query parameter with a given name
  • fromRequest().header(String key) - return the first header with a given name
  • fromRequest().header(String key, int index) - return the nth header with a given name
  • fromRequest().body() - return the full request body
  • fromRequest().body(String jsonPath) - return the element from the request that matches the JSON Path

Let’s take a look at the following contract

Contract contractDsl = Contract.make {
+of elements from the HTTP request. You can use the following options:

  • fromRequest().url() - return the request URL and query parameters
  • fromRequest().query(String key) - return the first query parameter with a given name
  • fromRequest().query(String key, int index) - return the nth query parameter with a given name
  • fromRequest().path() - return the full path
  • fromRequest().path(int index) - return the nth path element
  • fromRequest().header(String key) - return the first header with a given name
  • fromRequest().header(String key, int index) - return the nth header with a given name
  • fromRequest().body() - return the full request body
  • fromRequest().body(String jsonPath) - return the element from the request that matches the JSON Path

Let’s take a look at the following contract

Contract contractDsl = Contract.make {
 	request {
 		method 'GET'
 		url('/api/v1/xxxx') {
@@ -2640,6 +2640,8 @@ of elements from the HTTP request. You can use the following options:

1), param: fromRequest().query("foo"), paramIndex: fromRequest().query("foo", 1), authorization: fromRequest().header("Authorization"), @@ -2667,15 +2669,17 @@ of elements from the HTTP request. You can use the following options:

"Authorization")).isEqualTo("foo secret bar"); // and: DocumentContext parsedJson = JsonPath.parse(response.getBody().asString()); - assertThatJson(parsedJson).field("url").isEqualTo("/api/v1/xxxx"); - assertThatJson(parsedJson).field("fullBody").isEqualTo("{\"foo\":\"bar\",\"baz\":5}"); - assertThatJson(parsedJson).field("paramIndex").isEqualTo("bar2"); - assertThatJson(parsedJson).field("responseFoo").isEqualTo("bar"); - assertThatJson(parsedJson).field("authorization2").isEqualTo("secret2"); - assertThatJson(parsedJson).field("responseBaz").isEqualTo(5); - assertThatJson(parsedJson).field("responseBaz2").isEqualTo("Bla bla bar bla bla"); - assertThatJson(parsedJson).field("param").isEqualTo("bar"); - assertThatJson(parsedJson).field("authorization").isEqualTo("secret");

As you can see elements from the request have been properly referenced in the response.

The generated WireMock stub will look more or less like this:

{
+ assertThatJson(parsedJson).field("['fullBody']").isEqualTo("{\"foo\":\"bar\",\"baz\":5}");
+ assertThatJson(parsedJson).field("['authorization']").isEqualTo("secret");
+ assertThatJson(parsedJson).field("['authorization2']").isEqualTo("secret2");
+ assertThatJson(parsedJson).field("['path']").isEqualTo("/api/v1/xxxx");
+ assertThatJson(parsedJson).field("['param']").isEqualTo("bar");
+ assertThatJson(parsedJson).field("['paramIndex']").isEqualTo("bar2");
+ assertThatJson(parsedJson).field("['pathIndex']").isEqualTo("v1");
+ assertThatJson(parsedJson).field("['responseBaz']").isEqualTo(5);
+ assertThatJson(parsedJson).field("['responseFoo']").isEqualTo("bar");
+ assertThatJson(parsedJson).field("['url']").isEqualTo("/api/v1/xxxx?foo=bar&foo=bar2");
+ assertThatJson(parsedJson).field("['responseBaz2']").isEqualTo("Bla bla bar bla bla");

As you can see elements from the request have been properly referenced in the response.

The generated WireMock stub will look more or less like this:

{
   "request" : {
     "urlPath" : "/api/v1/xxxx",
     "method" : "POST",
@@ -2690,22 +2694,24 @@ of elements from the HTTP request. You can use the following options:

} }, "bodyPatterns" : [ { - "matchesJsonPath" : "$[?(@.baz == 5)]" + "matchesJsonPath" : "$[?(@.['baz'] == 5)]" }, { - "matchesJsonPath" : "$[?(@.foo == 'bar')]" + "matchesJsonPath" : "$[?(@.['foo'] == 'bar')]" } ] }, "response" : { "status" : 200, - "body" : "{\"url\":\"{{{request.url}}}\",\"param\":\"{{{request.query.foo.[0]}}}\",\"paramIndex\":\"{{{request.query.foo.[1]}}}\",\"authorization\":\"{{{request.headers.Authorization.[0]}}}\",\"authorization2\":\"{{{request.headers.Authorization.[1]}}}\",\"fullBody\":\"{{{escapejsonbody}}}\",\"responseFoo\":\"{{{jsonpath this '$.foo'}}}\",\"responseBaz\":{{{jsonpath this '$.baz'}}} ,\"responseBaz2\":\"Bla bla {{{jsonpath this '$.foo'}}} bla bla\"}", + "body" : "{\"authorization\":\"{{{request.headers.Authorization.[0]}}}\",\"path\":\"{{{request.path}}}\",\"responseBaz\":{{{jsonpath this '$.baz'}}} ,\"param\":\"{{{request.query.foo.[0]}}}\",\"pathIndex\":\"{{{request.path.[1]}}}\",\"responseBaz2\":\"Bla bla {{{jsonpath this '$.foo'}}} bla bla\",\"responseFoo\":\"{{{jsonpath this '$.foo'}}}\",\"authorization2\":\"{{{request.headers.Authorization.[1]}}}\",\"fullBody\":\"{{{escapejsonbody}}}\",\"url\":\"{{{request.url}}}\",\"paramIndex\":\"{{{request.query.foo.[1]}}}\"}", "headers" : { - "Authorization" : "{{{request.headers.Authorization.[0]}}}" + "Authorization" : "{{{request.headers.Authorization.[0]}}};foo" }, "transformers" : [ "response-template" ] } }

So sending a request as the one presented in the request part of the contract will lead in sending the following response body

{
   "url" : "/api/v1/xxxx?foo=bar&foo=bar2",
+  "path" : "/api/v1/xxxx",
+  "pathIndex" : "v1",
   "param" : "bar",
   "paramIndex" : "bar2",
   "authorization" : "secret",
@@ -2938,7 +2944,7 @@ that we took the method name and passed the proper JSON path as a parameter to i
   },
   "response" : {
     "status" : 200,
-    "body" : "{\\"duck\\":123,\\"alpha\\":\\"abc\\",\\"number\\":123,\\"aBoolean\\":true,\\"date\\":\\"2017-01-01\\",\\"dateTime\\":\\"2017-01-01T01:23:45\\",\\"time\\":\\"01:02:34\\",\\"valueWithoutAMatcher\\":\\"foo\\",\\"valueWithTypeMatch\\":\\"string\\",\\"valueWithMin\\":[1,2,3],\\"valueWithMax\\":[1,2,3],\\"valueWithMinMax\\":[1,2,3]}",
+    "body" : "{\\"date\\":\\"2017-01-01\\",\\"dateTime\\":\\"2017-01-01T01:23:45\\",\\"number\\":123,\\"aBoolean\\":true,\\"duck\\":123,\\"alpha\\":\\"abc\\",\\"valueWithMin\\":[1,2,3],\\"time\\":\\"01:02:34\\",\\"valueWithTypeMatch\\":\\"string\\",\\"valueWithMax\\":[1,2,3],\\"valueWithMinMax\\":[1,2,3],\\"valueWithoutAMatcher\\":\\"foo\\"}",
     "headers" : {
       "Content-Type" : "application/json"
     }
@@ -4225,4 +4231,6 @@ snippet above.

Maven.  have to implement that method too. It should return a String representing all mappings available in a single HttpServerStub. Related to issue 355.

11.2.2 New packages for generated tests

The flow for setting the generated tests package name will look like this:

  • pick basePackageForTests
  • if basePackageForTests wasn’t set pick the package from baseClassForTests
  • if baseClassForTests wasn’t set pick packageWithBaseClasses
  • if nothing got set pick the default org.springframework.cloud.contract.verifier.tests value

Related to -issue 260.

\ No newline at end of file +issue 260.

11.2.3 New methods in TemplateProcessor

In order to add support for fromRequest.path some methods had to be added to the +TemplateProcessor interface.

Related to +issue 388.

\ No newline at end of file diff --git a/2.0.x/spring-cloud-contract-maven-plugin/checkstyle.html b/2.0.x/spring-cloud-contract-maven-plugin/checkstyle.html index cbfa72f2bd..3fdaf28edb 100644 --- a/2.0.x/spring-cloud-contract-maven-plugin/checkstyle.html +++ b/2.0.x/spring-cloud-contract-maven-plugin/checkstyle.html @@ -1,13 +1,13 @@ - + Spring Cloud Contract Maven Plugin – Checkstyle Results @@ -146,7 +146,7 @@