org.springframework.cloud.contract.spec.Contract.make {
@@ -1599,8 +1727,8 @@ in the configuration. Please see the examples below:
Introduction
-
+
+
Introduction
-
HTTP Top-Level Elements
+
+
@@ -1214,8 +1342,8 @@ the value of a system property
HTTP Top-Level Elements
Following methods can be called in the top-level closure of a contract definition. Request and response are mandatory, priority is optional.
spring.cloud.contract.verifier.assert.size<
-
-Request
+
+
@@ -1368,8 +1496,8 @@ the value of a system property
Request
HTTP protocol requires only method and address to be specified in a request. The same information is mandatory in request definition of the Contract.
spring.cloud.contract.verifier.assert.size<
-
-Response
+
+
@@ -1391,8 +1519,8 @@ the value of a system property
Response
Minimal response must contain HTTP status code.
spring.cloud.contract.verifier.assert.size<
Besides status response may contain headers and body, which are specified the same way as in the request (see previous paragraph).
-
-Regular expressions
+
+
-Regular expressions
You can use regular expressions to write your requests in Contract DSL. It is particularly useful when you want to indicate that a given response should be provided for requests that follow a given pattern. Also, you can use it when you need to use patterns and not exact values both @@ -1459,8 +1587,8 @@ provide the generated string that matches the provided regular expression. For e
In this example for request and response the opposite side of the communication will have the respective data generated.
-
Passing optional parameters
+
+
@@ -1565,14 +1693,14 @@ provide the generated string that matches the provided regular expression. For e
Passing optional parameters
It is possible to provide optional parameters in your contract. It’s only possible to have optional parameter for the:
-
Executing custom methods on server side
+
+
-
Executing custom methods on server side
It is also possible to define a method call to be executed on the server side during the test. Such a method can be added to the class defined as "baseClassForTests" in the configuration. Please see the examples below:
-
Contract DSL
+
+
-Contract DSL
-
-Base Mock Spec
+
+
-Base Mock Spec
abstract class BaseMockMvcSpec extends Specification {
@@ -1622,8 +1750,8 @@ in the configuration. Please see the examples below:
-
JAX-RS support
+
+
@@ -1635,7 +1763,7 @@ in the configuration. Please see the examples below:
JAX-RS support
Starting with release 0.8.0 we support JAX-RS 2 Client API. Base class needs to define protected WebTarget webTarget and server initialization, right now the only option how to test JAX-RS API is to start a web server.
-
testMode == 'JAXRSCLIENT'testMode === 'JAXRSCLIENT'
@@ -1669,13 +1797,13 @@ in the configuration. Please see the examples below:
-
Messaging Top-Level Elements
+
+
-
-Messaging Top-Level Elements
The DSL for messaging looks a little bit different than the one that focuses on HTTP.
-
-Output triggered by a method
+
+
@@ -1710,8 +1838,8 @@ in the configuration. Please see the examples below:
we will generate a test that will call that method to trigger the message. On the consumer side you can use the
Output triggered by a method
The output message can be triggered by calling a method (e.g. a Scheduler was started and a message was sent)
some_label to trigger the message.
-
-Output triggered by a message
+
+
@@ -1751,8 +1879,8 @@ we will generate a test that will send the input message to the defined destinat
destination or use the
Output triggered by a message
The output message can be triggered by receiving a message.
some_label to trigger the message.
-
-Consumer / Producer
+
+
Consumer / Producer
In HTTP you have a notion of client/stub and `server/test notation. You can use them also in messaging but we’re providing also the consumer and produer methods
as presented below (note you can use either $ or value methods to provide consumer and producer parts)
$ or value
-
Spring Cloud Contract Verifier HTTP
-
-
Gradle Project
+Spring Cloud Contract Verifier HTTP
-
-Prerequisites
+Gradle Project
+
+
-
-Prerequisites
In order to use Spring Cloud Contract Verifier with WireMock you have to use gradle or maven plugin.
-
-Add gradle plugin
+
+
-
Add gradle plugin
buildscript {
@@ -1816,8 +1942,9 @@ dependencies {
}
-
@@ -1831,9 +1958,8 @@ dependencies {
Snapshot versions
+
+
======= Snapshot versions
+Add the additional snapshot repository to your build.gradle to use snapshot versions which are automatically uploaded after every successful build:
-
-Add maven plugin
+
+
-
-Add maven plugin
<plugin>
@@ -1855,8 +1981,8 @@ dependencies {
Read more: spring-cloud-contract-maven-plugin
-
Add stubs
+
+
@@ -1886,14 +2012,14 @@ src/test/resources/contracts/myservice/shouldReturnUser.groovy
Add stubs
By default Spring Cloud Contract Verifier is looking for stubs in src/test/resources/contracts directory.
-
-Run plugin
+
+
-Run plugin
Plugin registers itself to be invoked before check task. You have nothing to do as long as you want it to be part of your build process. If you just want to generate tests please invoke generateContractTests task.
-
Default setup
+
+
@@ -1936,8 +2062,8 @@ publishing {
Default setup
Default Gradle Plugin setup creates the following Gradle part of the build (it’s a pseudocode)
-
-Configure plugin
+
+
@@ -1950,8 +2076,8 @@ publishing {
}
Configure plugin
To change default configuration just add contractVerifier snippet to your Gradle config
-
-Configuration options
+
+
-Configuration options
- @@ -1990,8 +2116,8 @@ publishing {
-
Base class for tests
+
+
@@ -2020,8 +2146,8 @@ should also contain
Base class for tests
When using Spring Cloud Contract Verifier in default MockMvc you need to create a base specification for all generated acceptance tests. In this class you need to point to endpoint which should be verified.
protected WebTarget webTarget field, right now
-
Invoking generated tests
+
+
@@ -2031,8 +2157,8 @@ should also contain
Invoking generated tests
To ensure that provider side is complaint with defined contracts, you need to invoke:
protected WebTarget webTarget field, right now
-
Spring Cloud Contract Verifier on consumer side
+
+
@@ -2078,10 +2204,10 @@ class LoanApplicationServiceSpec extends Specification {
Spring Cloud Contract Verifier on consumer side
In consumer service you need to configure Spring Cloud Contract Verifier plugin in exactly the same way as in case of provider. If you don’t want to use Stub Runner then you need to copy contracts stored in
src/test/resources/contracts and generate WireMock json stubs using:
-
Using in your Maven project
-
Add maven plugin
+Using in your Maven project
+
+
-
Add maven plugin
<plugin>
@@ -2103,8 +2229,8 @@ class LoanApplicationServiceSpec extends Specification {
Read more: spring-cloud-contract-maven-plugin
-
Add stubs
+
+
-Add stubs
By default Spring Cloud Contract Verifier is looking for stubs in src/test/resources/contracts directory.
Directory containing stub definitions is treated as a class name, and each stub definition is treated as a single test.
@@ -2123,14 +2249,14 @@ src/test/resources/contracts/myservice/shouldReturnUser.groovy
- shouldReturnUser()
-
Run plugin
+
+
-Run plugin
Plugin goal generateTests is assigned to be invoked in phase generate-test-sources. You have nothing to do as long as you want it to be part of your build process. If you just want to generate tests please invoke generateTests goal.
-
-Configure plugin
+
+
@@ -2155,8 +2281,8 @@ src/test/resources/contracts/myservice/shouldReturnUser.groovy
</plugin>
Configure plugin
To change default configuration just add configuration section to plugin definition or execution definition.
-
Important configuration options
+
+
-Important configuration options
-
@@ -2183,8 +2309,8 @@ src/test/resources/contracts/myservice/shouldReturnUser.groovy
For complete information take a look at Plugin Documentation
-
-Base class for tests
+
+
-Base class for tests
When using Spring Cloud Contract Verifier in default MockMvc you need to create a base specification for all generated acceptance tests. In this class you need to point to endpoint which should be verified.@@ -2210,8 +2336,8 @@ class MvcSpec extends Specification {
-
-Invoking generated tests
+
+
@@ -2254,8 +2380,8 @@ class MvcSpec extends Specification {
Invoking generated tests
Spring Cloud Contract Verifier Maven Plugins generates verification code into directory /generated-test-sources/contractVerifier and attach this directory to testCompile goal.
To ensure that provider side is complaint with defined contracts, you need to invoke mvn generateTest test
-
Spring Cloud Contract Verifier on consumer side
+
+
@@ -2312,8 +2438,8 @@ class LoanApplicationServiceSpec extends Specification {
Spring Cloud Contract Verifier on consumer side
In consumer service you need to configure Spring Cloud Contract Verifier plugin in exactly the same way as in case of provider. You need to copy contracts stored in src/test/resources/contracts and generate Wiremock json stubs using: mvn generateStubs command. By default generated WireMock mapping is stored in directory target/mappings. Your project should create from this generated mappings additional artifact with classifier stubs for easy deploy to maven repository.
-
Scenarios
+
+
@@ -2338,16 +2464,14 @@ More details about Wiremock scenarios can be found under
-
-Scenarios
It’s possible to handle scenarios with Spring Cloud Contract Verifier. All you need to do is to stick to proper naming convention while creating your contracts. The convention requires to include order number followed by the underscore.
Spring Cloud Contract Verifier Messaging
-
+
-
+
-
-Spring Cloud Contract Verifier Messaging
Spring Cloud Contract Verifier allows you to verify your application that uses messaging as means of communication. All of our integrations are working with Spring but you can also set one yourself.
-
Integrations
+
+
@@ -2381,8 +2505,8 @@ testCompile "org.springframework.cloud:spring-cloud-contract-verifier-stream:${v
Integrations
You can use one of the three integration configurations:
-
Manual Integration
+
+
@@ -2415,8 +2539,8 @@ frameworks than Spring.
Manual Integration
The spring-cloud-contract-verifier-messaging-core module contains 3 main interfaces:
-
-Publisher side test generation
+
+
-
-Publisher side test generation
Having the input or outputMessage sections in your DSL will result in creation of tests on the publisher’s side. By default
JUnit tests will be created, however there is also a possibility to create Spock tests.
-
Scenario 1 (no input message)
+
+
@@ -2500,8 +2624,8 @@ inside the application (e.g. scheduler)
Scenario 1 (no input message)
For the given contract:
-
Scenario 2 (output triggered by input)
+
+
@@ -2581,8 +2705,8 @@ and:
Scenario 2 (output triggered by input)
For the given contract:
-
Scenario 3 (no output message)
+
+
@@ -2646,8 +2770,8 @@ then:
Scenario 3 (no output message)
For the given contract:
-
-Consumer Stub Side generation
+
+
-
-
-Consumer Stub Side generation
Unlike the HTTP part - in Messaging we need to publish the Groovy DSL inside the JAR with a stub. Then it’s parsed on the consumer side and proper stubbed routes are created.
@@ -2655,8 +2779,8 @@ and proper stubbed routes are created.For more infromation please consult the Stub Runner Messaging sections.
-
Gradle Setup
+
+
@@ -2683,18 +2807,16 @@ publishing {
Gradle Setup
Example of Spring Cloud Contract Verifier Gradle setup:
-
Maven Setup
+
+
Maven Setup
Example of Maven can be found in the Spring Cloud Contract Verifier README
-
Spring Cloud Contract Stub Runner
-
+
-
-
+
-
-
Spring Cloud Contract Stub Runner
One of the issues that you could have encountered while using Spring Cloud Contract Verifier was to pass the generated WireMock JSON stubs from the server side to the client side (or various clients). The same takes place in terms of client side generation for messaging.
@@ -2702,8 +2824,8 @@ publishing {Copying the JSON files / setting the client side for messaging manually is out of the question.
-
Snapshot versions
+
+
@@ -2717,13 +2839,13 @@ publishing {
Snapshot versions
Add the additional snapshot repository to your build.gradle to use snapshot versions which are automatically uploaded after every successful build:
-
+Publishing stubs as JARs
+
+
-
-Publishing stubs as JARs
The easiest approach would be to centralize the way stubs are kept. For example you can keep them as JARs in a Maven repository.
-
Gradle
+
+
@@ -2750,15 +2872,15 @@ publishing {
Gradle
Example of Spring Cloud Contract Verifier Gradle setup:
-
-Maven
+
+
Maven
Example of Maven can be found in the Spring Cloud Contract Verifier README
-
Modules
+
+
@@ -2773,6 +2895,7 @@ publishing {
Modules
Spring Cloud Contract Stub Runner comes with a new structure of modules
Stub Runner Core
@@ -3299,9 +3422,8 @@ You can disable Stub Runner Ribbon support by providing:
stubrunner.cloud.
You can disable Stub Runner support by providing: stubrunner.cloud.enabled equal to false
-
Common properties for JUnit and Spring
+
+
@@ -3351,8 +3473,8 @@ You can disable Stub Runner support by providing:
Common properties for JUnit and Spring
Some of the properties that are repetitive can be set using system properties or property sources (for Spring). Here are their names with their default values:
stubrunner.cloud.enabled
-
Stub runner stubs ids
+
+
@@ -3383,10 +3505,8 @@ You can disable Stub Runner support by providing:
Stub runner stubs ids
You can provide the stubs to download via the stubrunner.stubs.ids system property. They follow the following pattern:
stubrunner.cloud.enabled
-
Stub Runner for Messaging
-
+
+
@@ -3406,8 +3526,8 @@ You can disable Stub Runner support by providing:
Stub Runner for Messaging
Stub Runner has the functionality to run the published stubs in memory. It can integrate with the following frameworks out of the box
stubrunner.cloud.enabled
It also provides points of entry to integrate with any other solution on the market.
-
-Stub triggering
+
+Stub triggering
To trigger a message it’s enough to use the StubTrigger interface:
@@ -3475,29 +3595,30 @@ interface StubTrigger {
StubTrigger gives you the following options to trigger a message:
-
-Trigger by label
+
+Trigger by label
stubFinder.trigger('return_book_1')
-
-Trigger by group and artifact ids
+
+Trigger by group and artifact ids
stubFinder.trigger('org.springframework.cloud.contract.verifier.stubs:camelService', 'return_book_1')
-
-Trigger by artifact ids
+
+Trigger by artifact ids
stubFinder.trigger('camelService', 'return_book_1')
+
Trigger all messages
@@ -4113,11 +4234,8 @@ receivedMessage.headers.get('BOOK-NAME') == 'foo'
-
-
-
-Links
-
+
+Links
Here you can find interesting links related to Spring Cloud Contract Verifier:
@@ -4148,6 +4266,7 @@ receivedMessage.headers.get('BOOK-NAME') == 'foo'
+
Spring Cloud Contract WireMock
@@ -4163,7 +4282,7 @@ receivedMessage.headers.get('BOOK-NAME') == 'foo'