diff --git a/multi/multi__contract_dsl.html b/multi/multi__contract_dsl.html index a488f4b6e2..e0a65c04ac 100644 --- a/multi/multi__contract_dsl.html +++ b/multi/multi__contract_dsl.html @@ -359,7 +359,7 @@ the provided regular expression. The following code shows an example:

Spring Cloud Contract comes with a series of predefined regular expressions that you can use in your contracts, as shown in the following example:

protected static final Pattern TRUE_OR_FALSE = Pattern.compile(/(true|false)/)
 protected static final Pattern ONLY_ALPHA_UNICODE = Pattern.compile(/[\p{L}]*/)
-protected static final Pattern NUMBER = Pattern.compile('-?\\d*(\\.\\d+)?')
+protected static final Pattern NUMBER = Pattern.compile('-?(\\d*\\.\\d+|\\d+)')
 protected static final Pattern IP_ADDRESS = Pattern.compile('([01]?\\d\\d?|2[0-4]\\d|25[0-5])\\.([01]?\\d\\d?|2[0-4]\\d|25[0-5])\\.([01]?\\d\\d?|2[0-4]\\d|25[0-5])\\.([01]?\\d\\d?|2[0-4]\\d|25[0-5])')
 protected static final Pattern HOSTNAME_PATTERN = Pattern.compile('((http[s]?|ftp):/)/?([^:/\\s]+)(:[0-9]{1,5})?')
 protected static final Pattern EMAIL = Pattern.compile('[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,6}')
@@ -376,60 +376,60 @@ use in your contracts, as shown in the following example:

return Pattern.compile(values.collect({"^$it\$"}).join("|"))
 }
 
-String onlyAlphaUnicode() {
-	return ONLY_ALPHA_UNICODE.pattern()
+Pattern onlyAlphaUnicode() {
+	return ONLY_ALPHA_UNICODE
 }
 
-String number() {
-	return NUMBER.pattern()
+Pattern number() {
+	return NUMBER
 }
 
-String anyBoolean() {
-	return TRUE_OR_FALSE.pattern()
+Pattern anyBoolean() {
+	return TRUE_OR_FALSE
 }
 
-String ipAddress() {
-	return IP_ADDRESS.pattern()
+Pattern ipAddress() {
+	return IP_ADDRESS
 }
 
-String hostname() {
-	return HOSTNAME_PATTERN.pattern()
+Pattern hostname() {
+	return HOSTNAME_PATTERN
 }
 
-String email() {
-	return EMAIL.pattern()
+Pattern email() {
+	return EMAIL
 }
 
-String url() {
-	return URL.pattern()
+Pattern url() {
+	return URL
 }
 
-String uuid(){
-	return UUID.pattern()
+Pattern uuid(){
+	return UUID
 }
 
-String isoDate() {
-	return ANY_DATE.pattern()
+Pattern isoDate() {
+	return ANY_DATE
 }
 
-String isoDateTime() {
-	return ANY_DATE_TIME.pattern()
+Pattern isoDateTime() {
+	return ANY_DATE_TIME
 }
 
-String isoTime() {
-	return ANY_TIME.pattern()
+Pattern isoTime() {
+	return ANY_TIME
 }
 
-String iso8601WithOffset() {
-	return ISO8601_WITH_OFFSET.pattern()
+Pattern iso8601WithOffset() {
+	return ISO8601_WITH_OFFSET
 }
 
-String nonEmpty() {
-	return NON_EMPTY.pattern()
+Pattern nonEmpty() {
+	return NON_EMPTY
 }
 
-String nonBlank() {
-	return NON_BLANK.pattern()
+Pattern nonBlank() {
+	return NON_BLANK
 }

In your contract, you can use it as shown in the following example:

Contract dslWithOptionalsInString = Contract.make {
 	priority 1
 	request {
@@ -934,7 +934,7 @@ the method name and passed the proper JSON path as a parameter to it.

}, { "matchesJsonPath" : "$[?(@.alpha == 'abc')]" }, { - "matchesJsonPath" : "$[?(@.number =~ /(-?\\\\d*(\\\\.\\\\d+)?)/)]" + "matchesJsonPath" : "$[?(@.number =~ /(-?(\\\\d*\\\\.\\\\d+|\\\\d+))/)]" }, { "matchesJsonPath" : "$[?(@.aBoolean =~ /((true|false))/)]" }, { @@ -1060,7 +1060,7 @@ socket.

Consider the following contract:

or
 	}
 }

The following example shows how to set up a base class and Rest Assured:

import io.restassured.RestAssured;
 import org.junit.Before;
-import org.springframework.boot.context.embedded.LocalServerPort;
+import org.springframework.boot.web.server.LocalServerPort;
 import org.springframework.boot.test.context.SpringBootTest;
 
 @SpringBootTest(classes = ContextPathTestingBaseClass.class, webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
diff --git a/multi/multi__migrations.html b/multi/multi__migrations.html
index 7e5efdbd88..6c7c589f4c 100644
--- a/multi/multi__migrations.html
+++ b/multi/multi__migrations.html
@@ -92,4 +92,5 @@ you manually set versions of Spring Cloud Contract and the release train
 you might see the following exception:

Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile (default-testCompile) on project some-project: Compilation failure: Compilation failure:
 [ERROR] /some/path/SomeClass.java:[4,39] package com.jayway.restassured.response does not exist

This exception will occur due to the fact that the tests got generated with an old version of plugin and at test execution time you have an incompatible -version of the release train (and vice versa).

Done via issue 267

\ No newline at end of file +version of the release train (and vice versa).

Done via issue 267

12.3 1.2.x → 2.0.x

12.3.1 No Camel support

We will add back Apache Camel support only after this issue +gets fixed

\ No newline at end of file diff --git a/multi/multi__spring_cloud_contract_faq.html b/multi/multi__spring_cloud_contract_faq.html index 6c6bd5882a..1f974d14b3 100644 --- a/multi/multi__spring_cloud_contract_faq.html +++ b/multi/multi__spring_cloud_contract_faq.html @@ -115,15 +115,15 @@ 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>1.5.4.RELEASE</version> + <version>2.0.0.M6</version> <relativePath /> </parent> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <java.version>1.8</java.version> - <spring-cloud-contract.version>1.2.0.BUILD-SNAPSHOT</spring-cloud-contract.version> - <spring-cloud-dependencies.version>Edgware.BUILD-SNAPSHOT</spring-cloud-dependencies.version> + <spring-cloud-contract.version>2.0.0.BUILD-SNAPSHOT</spring-cloud-contract.version> + <spring-cloud-dependencies.version>Finchley.BUILD-SNAPSHOT</spring-cloud-dependencies.version> <excludeBuildFolders>true</excludeBuildFolders> </properties> diff --git a/multi/multi__spring_cloud_contract_stub_runner.html b/multi/multi__spring_cloud_contract_stub_runner.html index 3fb5ebbe80..f7ddef1819 100644 --- a/multi/multi__spring_cloud_contract_stub_runner.html +++ b/multi/multi__spring_cloud_contract_stub_runner.html @@ -89,7 +89,9 @@ it if you want to.

Maven.  <inherited>false</inherited> <configuration> <attach>true</attach> - <descriptor>${basedir}/src/assembly/stub.xml</descriptor> + <descriptors> + ${basedir}/src/assembly/stub.xml + </descriptors> </configuration> </execution> </executions> @@ -379,7 +381,6 @@ then(rule.findStubUrl(StubFinder interface and use its methods as presented below:

@ContextConfiguration(classes = Config, loader = SpringBootContextLoader)
 @SpringBootTest(properties = [" stubrunner.cloud.enabled=false",
-		"stubrunner.camel.enabled=false",
 		'foo=${stubrunner.runningstubs.fraudDetectionServer.port}'])
 @AutoConfigureStubRunner(mappingsOutputFolder = "target/outputmappings/")
 @DirtiesContext
@@ -526,7 +527,7 @@ the Stub Runner server. It will be available at port 8750<
 			def response = RestAssuredMockMvc.get("/stubs/${stubId}")
 		then:
 			response.statusCode == 200
-			response.body.as(Integer) > 0
+			Integer.valueOf(response.body.asString()) > 0
 		where:
 			stubId << ['org.springframework.cloud.contract.verifier.stubs:bootService:+:stubs',
 					   'org.springframework.cloud.contract.verifier.stubs:bootService:0.0.1-SNAPSHOT:stubs',
diff --git a/multi/multi__spring_cloud_contract_verifier_introduction.html b/multi/multi__spring_cloud_contract_verifier_introduction.html
index 7e65d06d49..6d186c2c50 100644
--- a/multi/multi__spring_cloud_contract_verifier_introduction.html
+++ b/multi/multi__spring_cloud_contract_verifier_introduction.html
@@ -9,14 +9,14 @@ produced by Spring Cloud Contract Verifier.
  • Messaging r Integration, Spring Cloud Stream, Spring AMQP, and Apache Camel. You can also set your own integrations.
  • Acceptance tests (in JUnit or Spock) are used to verify if server-side implementation of the API is compliant with the contract (server tests). A full test is generated by -Spring Cloud Contract Verifier.
  • 2.1 Why a Contract Verifier?

    Assume that we have a system consisting of multiple microservices:

    Microservices Architecture

    2.1.1 Testing issues

    If we wanted to test the application in top left corner to determine whether it can +Spring Cloud Contract Verifier.

    2.1 Why a Contract Verifier?

    Assume that we have a system consisting of multiple microservices:

    Microservices Architecture

    2.1.1 Testing issues

    If we wanted to test the application in top left corner to determine whether it can communicate with other services, we could do one of two things:

    • Deploy all microservices and perform end-to-end tests.
    • Mock other microservices in unit/integration tests.

    Both have their advantages but also a lot of disadvantages.

    Deploy all microservices and perform end to end tests

    Advantages:

    • Simulates production.
    • Tests real communication between services.

    Disadvantages:

    • To test one microservice, we have to deploy 6 microservices, a couple of databases, etc.
    • The environment where the tests run is locked for a single suite of tests (nobody else would be able to run the tests in the meantime).
    • They take a long time to run.
    • The feedback comes very late in the process.
    • They are extremely hard to debug.

    Mock other microservices in unit/integration tests

    Advantages:

    • They provide very fast feedback.
    • They have no infrastructure requirements.

    Disadvantages:

    • The implementor of the service creates stubs that might have nothing to do with reality.
    • You can go to production with passing tests and failing production.

    To solve the aforementioned issues, Spring Cloud Contract Verifier with Stub Runner was created. The main idea is to give you very fast feedback, without the need to set up the whole world of microservices. If you work on stubs, then the only applications you need -are those that your application directly uses.

    Stubbed Services

    Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were +are those that your application directly uses.

    Stubbed Services

    Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were created by the service that you’re calling. Also, if you can use them, it means that they were tested against the producer’s side. In short, you can trust those stubs.

    2.2 Purposes

    The main purposes of Spring Cloud Contract Verifier with Stub Runner are:

    • To ensure that WireMock/Messaging stubs (used when developing the client) do exactly what the actual server-side implementation does.
    • To promote ATDD method and Microservices architectural style.
    • To provide a way to publish changes in contracts that are immediately visible on both @@ -121,8 +121,8 @@ us. The current implementation of our system grants loans to everybody.

      As sprint, we must develop a new feature: if a client wants to borrow too much money, then we mark the client as a fraud.

      Technical remark - Fraud Detection has an artifact-id of http-server, while Loan Issuance has an artifact-id of http-client, and both have a group-id of com.example.

      Social remark - both client and server development teams need to communicate directly and -discuss changes while going through the process. CDC is all about communication.

      The server -side code is available here and the +discuss changes while going through the process. CDC is all about communication.

      The server +side code is available here and the client code here.

      [Tip]Tip

      In this case, the producer owns the contracts. Physically, all the contract are in the producer’s repository.

      2.4.1 Technical note

      If using the SNAPSHOT / Milestone / Release Candidate versions please add the following section to your build:

      Maven.  @@ -440,9 +440,7 @@ git merge --no-ff contract-change-pr

    Work o where the repository with your stubs is located. At this moment the stubs of the server side are automatically downloaded from Nexus/Artifactory. You can switch off the value of the workOffline parameter in your annotation. The following code shows an example of -achieving the same thing by changing the properties.

    stubrunner:
    -  ids: 'com.example:http-server-dsl:+:stubs:8080'
    -  repositoryRoot: http://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 +achieving the same thing by changing the properties.

    Unresolved directive in verifier_introduction.adoc - include::https://raw.githubusercontent.com/spring-cloud/spring-cloud-contract/2.0.x/samples/standalone/dsl/http-client/src/test/resources/application-test-repo.yaml[]

    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.7 Samples

    You can find some samples at diff --git a/multi/multi__spring_cloud_contract_verifier_messaging.html b/multi/multi__spring_cloud_contract_verifier_messaging.html index 9ee04b8bc5..0ddf64c23f 100644 --- a/multi/multi__spring_cloud_contract_verifier_messaging.html +++ b/multi/multi__spring_cloud_contract_verifier_messaging.html @@ -194,7 +194,7 @@ Stub Runner Messaging sections.

    Maven.  <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> - <version>Edgware.BUILD-SNAPSHOT</version> + <version>Finchley.BUILD-SNAPSHOT</version> <type>pom</type> <scope>import</scope> </dependency> diff --git a/multi/multi__spring_cloud_contract_verifier_setup.html b/multi/multi__spring_cloud_contract_verifier_setup.html index 9668ba050b..36e6d97b1d 100644 --- a/multi/multi__spring_cloud_contract_verifier_setup.html +++ b/multi/multi__spring_cloud_contract_verifier_setup.html @@ -375,11 +375,8 @@ extends com.example.base.BaseClass. This setting ta packageWithBaseClasses and baseClassForTests.

    If you want to download your contract definitions from a Maven repository, you can use the following options:

    • contractDependency: The contract dependency that contains all the packaged contracts.
    • contractsPath: The path to the concrete contracts in the JAR with packaged contracts. Defaults to groupid/artifactid where gropuid is slash separated.
    • contractsWorkOffline: Dictates whether the dependencies should be downloaded or the -local Maven artifacts should be reused.
    • contractsRepositoryUrl: DEPRECATED PROPERTY - please use the contractRepository -closure: URL to a repo with the artifacts that have contracts. If it is not provided, -use the current Maven ones.
    • contractRepository - Lets you use a closure where you can define properties related -to repository with contracts.
    • username: The user name to be used to connect to the repo.
    • password: The password to be used to connect to the repo.
    • proxyHost: The proxy host to be used to connect to the repo.
    • proxyPort: The proxy port to be used to connect to the repo.
    • cacheDownloadedContracts - Specifies whether to reuse downloaded JARs that contain -contract definitions.

    We cache only non-snapshot, explicitly provided versions (for example +local Maven artifacts should be reused.

  • contractsRepositoryUrl: URL to a repo with the artifacts that have contracts. If it is not provided, +use the current Maven ones.
  • contractsRepositoryUsername: The user name to be used to connect to the repo with contracts.
  • contractsRepositoryPassword: The password to be used to connect to the repo with contracts.
  • contractsRepositoryProxyHost: The proxy host to be used to connect to the repo with contracts.
  • contractsRepositoryProxyPort: The proxy port to be used to connect to the repo with contracts.
  • We cache only non-snapshot, explicitly provided versions (for example + or 1.0.0.BUILD-SNAPSHOT won’t get cached). By default, this feature is turned on.

    4.2.8 Single Base Class for All 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 an endpoint, which should be verified.

    package org.mycompany.tests
    @@ -458,7 +455,7 @@ goal.

    For Groovy Spock code, use the following:

    </testSources>
     	</configuration>
     </plugin>

    To ensure that provider side is compliant with defined contracts, you need to invoke -mvn generateTest test.

    4.2.11 Maven Plugin and STS

    If you see the following exception while using STS:

    STS Exception

    When you click on the error marker you should see something like this:

     plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring-
    +mvn generateTest test.

    4.2.11 Maven Plugin and STS

    If you see the following exception while using STS:

    STS Exception

    When you click on the error marker you should see something like this:

     plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring-
      cloud-contract-maven-plugin:1.1.0.M1:convert failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145) at
      org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:331) at org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1362) at
     ...
    diff --git a/multi/multi__spring_cloud_contract_wiremock.html b/multi/multi__spring_cloud_contract_wiremock.html
    index 326e85a640..608a4d8d95 100644
    --- a/multi/multi__spring_cloud_contract_wiremock.html
    +++ b/multi/multi__spring_cloud_contract_wiremock.html
    @@ -2,7 +2,7 @@
           
        11. Spring Cloud Contract WireMock

    11. Spring Cloud Contract WireMock

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

    If you have a Spring Boot application that uses Tomcat as an embedded server (which is the default with spring-boot-starter-web), you can add spring-cloud-contract-wiremock to your classpath and add @AutoConfigureWireMock in @@ -62,7 +62,7 @@ automatic loading of stubs, because they come from the root location in a subdirectory called "mappings". The value of files has no effect on the stubs loaded explicitly from the stubs attribute.

    11.3 Alternative: Using JUnit Rules

    For a more conventional WireMock experience, you can use JUnit @Rules to start and stop the server. To do so, use the WireMockSpring convenience class to obtain an Options -instance, as shown in the followin example:

    @RunWith(SpringRunner.class)
    +instance, as shown in the following example:

    @RunWith(SpringRunner.class)
     @SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
     public class WiremockForDocsClassRuleTests {
     
    diff --git a/multi/multi__stub_runner_for_messaging.html b/multi/multi__stub_runner_for_messaging.html
    index cf1354d00c..cfa743cbc3 100644
    --- a/multi/multi__stub_runner_for_messaging.html
    +++ b/multi/multi__stub_runner_for_messaging.html
    @@ -1,7 +1,7 @@
     
           
        7. Stub Runner for Messaging

    7. Stub Runner for Messaging

    Stub Runner can run the published stubs in memory. It can integrate with the following -frameworks:

    • Spring Integration
    • Spring Cloud Stream
    • Apache Camel
    • Spring AMQP

    It also provides entry points to integrate with any other solution on the market.

    [Important]Important

    If you have multiple frameworks on the classpath Stub Runner will need to +frameworks:

    • Spring Integration
    • Spring Cloud Stream
    • Spring AMQP

    It also provides entry points to integrate with any other solution on the market.

    [Important]Important

    If you have multiple frameworks on the classpath Stub Runner will need to define which one should be used. Let’s assume that you have both AMQP, Spring Cloud Stream and Spring Integration on the classpath. Then you need to set stubrunner.stream.enabled=false and stubrunner.integration.enabled=false. That way the only remaining framework is Spring AMQP.

    7.1 Stub triggering

    To trigger a message, use the StubTrigger interface:

    package org.springframework.cloud.contract.stubrunner;
    @@ -45,72 +45,10 @@ That way the only remaining framework is Spring AMQP.

    Map<String, Collection<String>> labels(); }

    For convenience, the StubFinder interface extends StubTrigger, so you only need one -or the other in your tests.

    StubTrigger gives you the following options to trigger a message:

    7.1.1 Trigger by Label

    stubFinder.trigger('return_book_1')

    7.1.2 Trigger by Group and Artifact Ids

    stubFinder.trigger('org.springframework.cloud.contract.verifier.stubs:camelService', 'return_book_1')

    7.1.3 Trigger by Artifact Ids

    stubFinder.trigger('camelService', 'return_book_1')

    7.1.4 Trigger All Messages

    stubFinder.trigger()

    7.2 Stub Runner Camel

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to -integrate with Apache Camel. For the provided artifacts, it automatically downloads the -stubs and registers the required routes.

    7.2.1 Adding the Runner to the Project

    You can have both Apache Camel and Spring Cloud Contract Stub Runner on the classpath. -Remember to annotate your test class with @AutoConfigureStubRunner.

    7.2.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.camel.enabled=false -property.

    Assume that you have the following Maven repository with deployed stubs for the -camelService application:

    └── .m2
    -    └── repository
    -        └── io
    -            └── codearte
    -                └── accurest
    -                    └── stubs
    -                        └── camelService
    -                            ├── 0.0.1-SNAPSHOT
    -                            │   ├── camelService-0.0.1-SNAPSHOT.pom
    -                            │   ├── camelService-0.0.1-SNAPSHOT-stubs.jar
    -                            │   └── maven-metadata-local.xml
    -                            └── maven-metadata-local.xml

    Further assume that the stubs contain the following structure:

    ├── META-INF
    -│   └── MANIFEST.MF
    -└── repository
    -    ├── accurest
    -    │   ├── bookDeleted.groovy
    -    │   ├── bookReturned1.groovy
    -    │   └── bookReturned2.groovy
    -    └── mappings

    Consider the following contracts (numbered 1):

    Contract.make {
    -	label 'return_book_1'
    -	input {
    -		triggeredBy('bookReturnedTriggered()')
    -	}
    -	outputMessage {
    -		sentTo('jms:output')
    -		body('''{ "bookName" : "foo" }''')
    -		headers {
    -			header('BOOK-NAME', 'foo')
    -		}
    -	}
    -}

    Now consider 2

    Contract.make {
    -	label 'return_book_2'
    -	input {
    -		messageFrom('jms:input')
    -		messageBody([
    -				bookName: 'foo'
    -		])
    -		messageHeaders {
    -			header('sample', 'header')
    -		}
    -	}
    -	outputMessage {
    -		sentTo('jms:output')
    -		body([
    -				bookName: 'foo'
    -		])
    -		headers {
    -			header('BOOK-NAME', 'foo')
    -		}
    -	}
    -}

    These examples lend themselves to three scenarios:

    Scenario 1 (no input message)

    To trigger a message via the return_book_1 label, use the StubTigger interface, as -follows:

    stubFinder.trigger('return_book_1')

    To listen to the output of the message sent to jms:output:

    Exchange receivedMessage = camelContext.createConsumerTemplate().receive('jms:output', 5000)

    The received message passes the following assertions:

    receivedMessage != null
    -assertThatBodyContainsBookNameFoo(receivedMessage.in.body)
    -receivedMessage.in.headers.get('BOOK-NAME') == 'foo'

    Scenario 2 (output triggered by input)

    Since the route is set for you, you can send a message to the jms:output -destination:

    camelContext.createProducerTemplate().sendBodyAndHeaders('jms:input', new BookReturned('foo'), [sample: 'header'])

    You can listen to the output of the message sent to jms:output:

    Exchange receivedMessage = camelContext.createConsumerTemplate().receive('jms:output', 5000)

    The received message passes the following assertions:

    receivedMessage != null
    -assertThatBodyContainsBookNameFoo(receivedMessage.in.body)
    -receivedMessage.in.headers.get('BOOK-NAME') == 'foo'

    Scenario 3 (input with no output)

    Since the route is set for you, you can send a message to the jms:output -destination:

    camelContext.createProducerTemplate().sendBodyAndHeaders('jms:delete', new BookReturned('foo'), [sample: 'header'])

    7.3 Stub Runner Integration

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to +or the other in your tests.

    StubTrigger gives you the following options to trigger a message:

    7.1.1 Trigger by Label

    stubFinder.trigger('return_book_1')

    7.1.2 Trigger by Group and Artifact Ids

    stubFinder.trigger('org.springframework.cloud.contract.verifier.stubs:streamService', 'return_book_1')

    7.1.3 Trigger by Artifact Ids

    stubFinder.trigger('streamService', 'return_book_1')

    7.1.4 Trigger All Messages

    stubFinder.trigger()

    7.2 Stub Runner Integration

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to integrate with Spring Integration. For the provided artifacts, it automatically downloads -the stubs and registers the required routes.

    7.3.1 Adding the Runner to the Project

    You can have both Spring Integration and Spring Cloud Contract Stub Runner on the -classpath. Remember to annotate your test class with @AutoConfigureStubRunner.

    7.3.2 Disabling the functionality

    If you need to disable this functionality, set the +the stubs and registers the required routes.

    7.2.1 Adding the Runner to the Project

    You can have both Spring Integration and Spring Cloud Contract Stub Runner on the +classpath. Remember to annotate your test class with @AutoConfigureStubRunner.

    7.2.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.integration.enabled=false property.

    Assume that you have the following Maven repository with deployed stubs for the integrationService application:

    └── .m2
         └── repository
    @@ -186,7 +124,7 @@ assertJsons(receivedMessage.payload)
     receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 2 (output triggered by input)

    Since the route is set for you, you can send a message to the output destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'input')

    To listen to the output of the message sent to output:

    Message<?> receivedMessage = messaging.receive('outputTest')

    The received message passes the following assertions:

    receivedMessage != null
     assertJsons(receivedMessage.payload)
    -receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 3 (input with no output)

    Since the route is set for you, you can send a message to the input destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete')

    7.4 Stub Runner Stream

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to +receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 3 (input with no output)

    Since the route is set for you, you can send a message to the input destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete')

    7.3 Stub Runner Stream

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to integrate with Spring Stream. For the provided artifacts, it automatically downloads the stubs and registers the required routes.

    [Warning]Warning

    If Stub Runner’s integration with Stream the messageFrom or sentTo Strings are resolved first as a destination of a channel and no such destination exists, the @@ -199,8 +137,8 @@ destination is resolved as a channel name.

    </dependency>

    Gradle. 

    testCompile "org.springframework.cloud:spring-cloud-stream-test-support"

    -

    7.4.1 Adding the Runner to the Project

    You can have both Spring Cloud Stream and Spring Cloud Contract Stub Runner on the -classpath. Remember to annotate your test class with @AutoConfigureStubRunner.

    7.4.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.stream.enabled=false +

    7.3.1 Adding the Runner to the Project

    You can have both Spring Cloud Stream and Spring Cloud Contract Stub Runner on the +classpath. Remember to annotate your test class with @AutoConfigureStubRunner.

    7.3.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.stream.enabled=false property.

    Assume that you have the following Maven repository with a deployed stubs for the streamService application:

    └── .m2
         └── repository
    @@ -267,7 +205,7 @@ receivedMessage.headers.get(destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'bookStorage')

    To listen to the output of the message sent to returnBook:

    Message<?> receivedMessage = messaging.receive('returnBook')

    The received message passes the following assertions:

    receivedMessage != null
     assertJsons(receivedMessage.payload)
     receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 3 (input with no output)

    Since the route is set for you, you can send a message to the output -destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete')

    7.5 Stub Runner Spring AMQP

    Spring Cloud Contract Verifier Stub Runner’s messaging module provides an easy way to +destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete')

    7.4 Stub Runner Spring AMQP

    Spring Cloud Contract Verifier Stub Runner’s messaging module provides an easy way to integrate with Spring AMQP’s Rabbit Template. For the provided artifacts, it automatically downloads the stubs and registers the required routes.

    The integration tries to work standalone (that is, without interaction with a running RabbitMQ message broker). It expects a RabbitTemplate on the application context and @@ -279,7 +217,7 @@ queues. Bindings connect an exchange to a queue. If message contracts are trigge Spring AMQP stub runner integration looks for bindings on the application context that match this exchange. Then it collects the queues from the Spring exchanges and tries to find message listeners bound to these queues. The message is triggered for all matching -message listeners.

    7.5.1 Adding the Runner to the Project

    You can have both Spring AMQP and Spring Cloud Contract Stub Runner on the classpath and +message listeners.

    7.4.1 Adding the Runner to the Project

    You can have both Spring AMQP and Spring Cloud Contract Stub Runner on the classpath and set the property stubrunner.amqp.enabled=true. Remember to annotate your test class with @AutoConfigureStubRunner.

    [Important]Important

    If you already have Stream and Integration on the classpath, you need to disable them explicitly by setting the stubrunner.stream.enabled=false and diff --git a/multi/multi_pr01.html b/multi/multi_pr01.html index a836b44348..3436568f42 100644 --- a/multi/multi_pr01.html +++ b/multi/multi_pr01.html @@ -1,4 +1,4 @@

    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

    1.2.0.BUILD-SNAPSHOT

    \ No newline at end of file +Olga Maciaszek-Sharma, Mariusz Smykuła, Dave Syer, Jay Bryant

    2.0.0.BUILD-SNAPSHOT

    \ No newline at end of file diff --git a/multi/multi_spring-cloud-contract.html b/multi/multi_spring-cloud-contract.html index f3c3707c9f..fadbbf1b9c 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


    Table of Contents

    1. Spring Cloud Contract
    2. Spring Cloud Contract Verifier Introduction
    2.1. Why a Contract Verifier?
    2.1.1. Testing issues
    2.2. Purposes
    2.3. How It Works
    2.3.1. Defining the contract
    2.3.2. Client Side
    2.3.3. Server Side
    2.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
    2.4.1. Technical note
    2.4.2. Consumer side (Loan Issuance)
    2.4.3. Producer side (Fraud Detection server)
    2.4.4. Consumer Side (Loan Issuance) Final Step
    2.5. Dependencies
    2.6. Additional Links
    2.6.1. Spring Cloud Contract video
    2.6.2. Readings
    2.7. Samples
    3. Spring Cloud Contract FAQ
    3.1. Why use Spring Cloud Contract Verifier and not X ?
    3.2. What is this value(consumer(), producer()) ?
    3.3. How to do Stubs versioning?
    3.3.1. API Versioning
    3.3.2. JAR versioning
    3.3.3. Dev or prod stubs
    3.4. Common repo with contracts
    3.4.1. Repo structure
    3.4.2. Workflow
    3.4.3. Consumer
    3.4.4. Producer
    3.5. Can I have multiple base classes for tests?
    3.6. How can I debug the request/response being sent by the generated tests client?
    3.6.1. How can I debug the mapping/request/response being sent by WireMock?
    3.6.2. How can I see what got registered in the HTTP server stub?
    3.6.3. Can I reference the request from the response?
    3.6.4. 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. 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. Maven Plugin and STS
    4.2.12. Spring Cloud Contract Verifier on the Consumer Side
    4.3. Stubs and Transitive Dependencies
    4.4. Scenarios
    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
    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
    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 Camel
    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 Integration
    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 Stream
    7.4.1. Adding the Runner to the Project
    7.4.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    7.5. Stub Runner Spring AMQP
    7.5.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
    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. Generating Stubs using REST Docs
    11.7. 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
    13. 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 a Contract Verifier?
    2.1.1. Testing issues
    2.2. Purposes
    2.3. How It Works
    2.3.1. Defining the contract
    2.3.2. Client Side
    2.3.3. Server Side
    2.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
    2.4.1. Technical note
    2.4.2. Consumer side (Loan Issuance)
    2.4.3. Producer side (Fraud Detection server)
    2.4.4. Consumer Side (Loan Issuance) Final Step
    2.5. Dependencies
    2.6. Additional Links
    2.6.1. Spring Cloud Contract video
    2.6.2. Readings
    2.7. Samples
    3. Spring Cloud Contract FAQ
    3.1. Why use Spring Cloud Contract Verifier and not X ?
    3.2. What is this value(consumer(), producer()) ?
    3.3. How to do Stubs versioning?
    3.3.1. API Versioning
    3.3.2. JAR versioning
    3.3.3. Dev or prod stubs
    3.4. Common repo with contracts
    3.4.1. Repo structure
    3.4.2. Workflow
    3.4.3. Consumer
    3.4.4. Producer
    3.5. Can I have multiple base classes for tests?
    3.6. How can I debug the request/response being sent by the generated tests client?
    3.6.1. How can I debug the mapping/request/response being sent by WireMock?
    3.6.2. How can I see what got registered in the HTTP server stub?
    3.6.3. Can I reference the request from the response?
    3.6.4. 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. 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. Maven Plugin and STS
    4.2.12. Spring Cloud Contract Verifier on the Consumer Side
    4.3. Stubs and Transitive Dependencies
    4.4. Scenarios
    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
    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
    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
    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. Generating Stubs using REST Docs
    11.7. 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
    \ No newline at end of file diff --git a/single/spring-cloud-contract.html b/single/spring-cloud-contract.html index 0d4cd31f88..527d604789 100644 --- a/single/spring-cloud-contract.html +++ b/single/spring-cloud-contract.html @@ -1,7 +1,7 @@ - Spring Cloud Contract

    Spring Cloud Contract


    Table of Contents

    1. Spring Cloud Contract
    2. Spring Cloud Contract Verifier Introduction
    2.1. Why a Contract Verifier?
    2.1.1. Testing issues
    2.2. Purposes
    2.3. How It Works
    2.3.1. Defining the contract
    2.3.2. Client Side
    2.3.3. Server Side
    2.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
    2.4.1. Technical note
    2.4.2. Consumer side (Loan Issuance)
    2.4.3. Producer side (Fraud Detection server)
    2.4.4. Consumer Side (Loan Issuance) Final Step
    2.5. Dependencies
    2.6. Additional Links
    2.6.1. Spring Cloud Contract video
    2.6.2. Readings
    2.7. Samples
    3. Spring Cloud Contract FAQ
    3.1. Why use Spring Cloud Contract Verifier and not X ?
    3.2. What is this value(consumer(), producer()) ?
    3.3. How to do Stubs versioning?
    3.3.1. API Versioning
    3.3.2. JAR versioning
    3.3.3. Dev or prod stubs
    3.4. Common repo with contracts
    3.4.1. Repo structure
    3.4.2. Workflow
    3.4.3. Consumer
    3.4.4. Producer
    3.5. Can I have multiple base classes for tests?
    3.6. How can I debug the request/response being sent by the generated tests client?
    3.6.1. How can I debug the mapping/request/response being sent by WireMock?
    3.6.2. How can I see what got registered in the HTTP server stub?
    3.6.3. Can I reference the request from the response?
    3.6.4. 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. 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. Maven Plugin and STS
    4.2.12. Spring Cloud Contract Verifier on the Consumer Side
    4.3. Stubs and Transitive Dependencies
    4.4. Scenarios
    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
    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
    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 Camel
    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 Integration
    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 Stream
    7.4.1. Adding the Runner to the Project
    7.4.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    7.5. Stub Runner Spring AMQP
    7.5.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
    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. Generating Stubs using REST Docs
    11.7. 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
    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

    1.2.0.BUILD-SNAPSHOT

    1. Spring Cloud Contract

    You need confidence when pushing new features to a new application or service in a + Spring Cloud Contract

    Spring Cloud Contract


    Table of Contents

    1. Spring Cloud Contract
    2. Spring Cloud Contract Verifier Introduction
    2.1. Why a Contract Verifier?
    2.1.1. Testing issues
    2.2. Purposes
    2.3. How It Works
    2.3.1. Defining the contract
    2.3.2. Client Side
    2.3.3. Server Side
    2.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
    2.4.1. Technical note
    2.4.2. Consumer side (Loan Issuance)
    2.4.3. Producer side (Fraud Detection server)
    2.4.4. Consumer Side (Loan Issuance) Final Step
    2.5. Dependencies
    2.6. Additional Links
    2.6.1. Spring Cloud Contract video
    2.6.2. Readings
    2.7. Samples
    3. Spring Cloud Contract FAQ
    3.1. Why use Spring Cloud Contract Verifier and not X ?
    3.2. What is this value(consumer(), producer()) ?
    3.3. How to do Stubs versioning?
    3.3.1. API Versioning
    3.3.2. JAR versioning
    3.3.3. Dev or prod stubs
    3.4. Common repo with contracts
    3.4.1. Repo structure
    3.4.2. Workflow
    3.4.3. Consumer
    3.4.4. Producer
    3.5. Can I have multiple base classes for tests?
    3.6. How can I debug the request/response being sent by the generated tests client?
    3.6.1. How can I debug the mapping/request/response being sent by WireMock?
    3.6.2. How can I see what got registered in the HTTP server stub?
    3.6.3. Can I reference the request from the response?
    3.6.4. 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. 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. Maven Plugin and STS
    4.2.12. Spring Cloud Contract Verifier on the Consumer Side
    4.3. Stubs and Transitive Dependencies
    4.4. Scenarios
    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
    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
    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
    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. Generating Stubs using REST Docs
    11.7. 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), covering a range of options for writing tests, publishing them as assets, and asserting @@ -14,14 +14,14 @@ produced by Spring Cloud Contract Verifier.

  • Messaging r Integration, Spring Cloud Stream, Spring AMQP, and Apache Camel. You can also set your own integrations.
  • Acceptance tests (in JUnit or Spock) are used to verify if server-side implementation of the API is compliant with the contract (server tests). A full test is generated by -Spring Cloud Contract Verifier.
  • 2.1 Why a Contract Verifier?

    Assume that we have a system consisting of multiple microservices:

    Microservices Architecture

    2.1.1 Testing issues

    If we wanted to test the application in top left corner to determine whether it can +Spring Cloud Contract Verifier.

    2.1 Why a Contract Verifier?

    Assume that we have a system consisting of multiple microservices:

    Microservices Architecture

    2.1.1 Testing issues

    If we wanted to test the application in top left corner to determine whether it can communicate with other services, we could do one of two things:

    • Deploy all microservices and perform end-to-end tests.
    • Mock other microservices in unit/integration tests.

    Both have their advantages but also a lot of disadvantages.

    Deploy all microservices and perform end to end tests

    Advantages:

    • Simulates production.
    • Tests real communication between services.

    Disadvantages:

    • To test one microservice, we have to deploy 6 microservices, a couple of databases, etc.
    • The environment where the tests run is locked for a single suite of tests (nobody else would be able to run the tests in the meantime).
    • They take a long time to run.
    • The feedback comes very late in the process.
    • They are extremely hard to debug.

    Mock other microservices in unit/integration tests

    Advantages:

    • They provide very fast feedback.
    • They have no infrastructure requirements.

    Disadvantages:

    • The implementor of the service creates stubs that might have nothing to do with reality.
    • You can go to production with passing tests and failing production.

    To solve the aforementioned issues, Spring Cloud Contract Verifier with Stub Runner was created. The main idea is to give you very fast feedback, without the need to set up the whole world of microservices. If you work on stubs, then the only applications you need -are those that your application directly uses.

    Stubbed Services

    Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were +are those that your application directly uses.

    Stubbed Services

    Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were created by the service that you’re calling. Also, if you can use them, it means that they were tested against the producer’s side. In short, you can trust those stubs.

    2.2 Purposes

    The main purposes of Spring Cloud Contract Verifier with Stub Runner are:

    • To ensure that WireMock/Messaging stubs (used when developing the client) do exactly what the actual server-side implementation does.
    • To promote ATDD method and Microservices architectural style.
    • To provide a way to publish changes in contracts that are immediately visible on both @@ -126,8 +126,8 @@ us. The current implementation of our system grants loans to everybody.

      As sprint, we must develop a new feature: if a client wants to borrow too much money, then we mark the client as a fraud.

      Technical remark - Fraud Detection has an artifact-id of http-server, while Loan Issuance has an artifact-id of http-client, and both have a group-id of com.example.

      Social remark - both client and server development teams need to communicate directly and -discuss changes while going through the process. CDC is all about communication.

      The server -side code is available here and the +discuss changes while going through the process. CDC is all about communication.

      The server +side code is available here and the client code here.

      [Tip]Tip

      In this case, the producer owns the contracts. Physically, all the contract are in the producer’s repository.

      2.4.1 Technical note

      If using the SNAPSHOT / Milestone / Release Candidate versions please add the following section to your build:

      Maven.  @@ -445,9 +445,7 @@ git merge --no-ff contract-change-pr

      Work o where the repository with your stubs is located. At this moment the stubs of the server side are automatically downloaded from Nexus/Artifactory. You can switch off the value of the workOffline parameter in your annotation. The following code shows an example of -achieving the same thing by changing the properties.

      stubrunner:
      -  ids: 'com.example:http-server-dsl:+:stubs:8080'
      -  repositoryRoot: http://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 +achieving the same thing by changing the properties.

    Unresolved directive in verifier_introduction.adoc - include::https://raw.githubusercontent.com/spring-cloud/spring-cloud-contract/2.0.x/samples/standalone/dsl/http-client/src/test/resources/application-test-repo.yaml[]

    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.7 Samples

    You can find some samples at @@ -566,15 +564,15 @@ 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>1.5.4.RELEASE</version> + <version>2.0.0.M6</version> <relativePath /> </parent> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <java.version>1.8</java.version> - <spring-cloud-contract.version>1.2.0.BUILD-SNAPSHOT</spring-cloud-contract.version> - <spring-cloud-dependencies.version>Edgware.BUILD-SNAPSHOT</spring-cloud-dependencies.version> + <spring-cloud-contract.version>2.0.0.BUILD-SNAPSHOT</spring-cloud-contract.version> + <spring-cloud-dependencies.version>Finchley.BUILD-SNAPSHOT</spring-cloud-dependencies.version> <excludeBuildFolders>true</excludeBuildFolders> </properties> @@ -1124,11 +1122,8 @@ extends com.example.base.BaseClass. This setting ta packageWithBaseClasses and baseClassForTests.

    If you want to download your contract definitions from a Maven repository, you can use the following options:

    • contractDependency: The contract dependency that contains all the packaged contracts.
    • contractsPath: The path to the concrete contracts in the JAR with packaged contracts. Defaults to groupid/artifactid where gropuid is slash separated.
    • contractsWorkOffline: Dictates whether the dependencies should be downloaded or the -local Maven artifacts should be reused.
    • contractsRepositoryUrl: DEPRECATED PROPERTY - please use the contractRepository -closure: URL to a repo with the artifacts that have contracts. If it is not provided, -use the current Maven ones.
    • contractRepository - Lets you use a closure where you can define properties related -to repository with contracts.
    • username: The user name to be used to connect to the repo.
    • password: The password to be used to connect to the repo.
    • proxyHost: The proxy host to be used to connect to the repo.
    • proxyPort: The proxy port to be used to connect to the repo.
    • cacheDownloadedContracts - Specifies whether to reuse downloaded JARs that contain -contract definitions.

    We cache only non-snapshot, explicitly provided versions (for example +local Maven artifacts should be reused.

  • contractsRepositoryUrl: URL to a repo with the artifacts that have contracts. If it is not provided, +use the current Maven ones.
  • contractsRepositoryUsername: The user name to be used to connect to the repo with contracts.
  • contractsRepositoryPassword: The password to be used to connect to the repo with contracts.
  • contractsRepositoryProxyHost: The proxy host to be used to connect to the repo with contracts.
  • contractsRepositoryProxyPort: The proxy port to be used to connect to the repo with contracts.
  • We cache only non-snapshot, explicitly provided versions (for example + or 1.0.0.BUILD-SNAPSHOT won’t get cached). By default, this feature is turned on.

    4.2.8 Single Base Class for All 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 an endpoint, which should be verified.

    package org.mycompany.tests
    @@ -1207,7 +1202,7 @@ goal.

    For Groovy Spock code, use the following:

    </testSources>
     	</configuration>
     </plugin>

    To ensure that provider side is compliant with defined contracts, you need to invoke -mvn generateTest test.

    4.2.11 Maven Plugin and STS

    If you see the following exception while using STS:

    STS Exception

    When you click on the error marker you should see something like this:

     plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring-
    +mvn generateTest test.

    4.2.11 Maven Plugin and STS

    If you see the following exception while using STS:

    STS Exception

    When you click on the error marker you should see something like this:

     plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring-
      cloud-contract-maven-plugin:1.1.0.M1:convert failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145) at
      org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:331) at org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1362) at
     ...
    @@ -1504,7 +1499,7 @@ Stub Runner Messaging sections.

    Maven.  <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> - <version>Edgware.BUILD-SNAPSHOT</version> + <version>Finchley.BUILD-SNAPSHOT</version> <type>pom</type> <scope>import</scope> </dependency> @@ -1618,7 +1613,9 @@ it if you want to.

    Maven.  <inherited>false</inherited> <configuration> <attach>true</attach> - <descriptor>${basedir}/src/assembly/stub.xml</descriptor> + <descriptors> + ${basedir}/src/assembly/stub.xml + </descriptors> </configuration> </execution> </executions> @@ -1908,7 +1905,6 @@ then(rule.findStubUrl(StubFinder interface and use its methods as presented below:

    @ContextConfiguration(classes = Config, loader = SpringBootContextLoader)
     @SpringBootTest(properties = [" stubrunner.cloud.enabled=false",
    -		"stubrunner.camel.enabled=false",
     		'foo=${stubrunner.runningstubs.fraudDetectionServer.port}'])
     @AutoConfigureStubRunner(mappingsOutputFolder = "target/outputmappings/")
     @DirtiesContext
    @@ -2055,7 +2051,7 @@ the Stub Runner server. It will be available at port 8750<
     			def response = RestAssuredMockMvc.get("/stubs/${stubId}")
     		then:
     			response.statusCode == 200
    -			response.body.as(Integer) > 0
    +			Integer.valueOf(response.body.asString()) > 0
     		where:
     			stubId << ['org.springframework.cloud.contract.verifier.stubs:bootService:+:stubs',
     					   'org.springframework.cloud.contract.verifier.stubs:bootService:0.0.1-SNAPSHOT:stubs',
    @@ -2215,7 +2211,7 @@ downloaded.

    port means the port o would like the Stub Runner to take into consideration. You can read more about the Aether versioning ranges here.

    7. Stub Runner for Messaging

    Stub Runner can run the published stubs in memory. It can integrate with the following -frameworks:

    • Spring Integration
    • Spring Cloud Stream
    • Apache Camel
    • Spring AMQP

    It also provides entry points to integrate with any other solution on the market.

    [Important]Important

    If you have multiple frameworks on the classpath Stub Runner will need to +frameworks:

    • Spring Integration
    • Spring Cloud Stream
    • Spring AMQP

    It also provides entry points to integrate with any other solution on the market.

    [Important]Important

    If you have multiple frameworks on the classpath Stub Runner will need to define which one should be used. Let’s assume that you have both AMQP, Spring Cloud Stream and Spring Integration on the classpath. Then you need to set stubrunner.stream.enabled=false and stubrunner.integration.enabled=false. That way the only remaining framework is Spring AMQP.

    7.1 Stub triggering

    To trigger a message, use the StubTrigger interface:

    package org.springframework.cloud.contract.stubrunner;
    @@ -2259,72 +2255,10 @@ That way the only remaining framework is Spring AMQP.

    Map<String, Collection<String>> labels(); }

    For convenience, the StubFinder interface extends StubTrigger, so you only need one -or the other in your tests.

    StubTrigger gives you the following options to trigger a message:

    7.1.1 Trigger by Label

    stubFinder.trigger('return_book_1')

    7.1.2 Trigger by Group and Artifact Ids

    stubFinder.trigger('org.springframework.cloud.contract.verifier.stubs:camelService', 'return_book_1')

    7.1.3 Trigger by Artifact Ids

    stubFinder.trigger('camelService', 'return_book_1')

    7.1.4 Trigger All Messages

    stubFinder.trigger()

    7.2 Stub Runner Camel

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to -integrate with Apache Camel. For the provided artifacts, it automatically downloads the -stubs and registers the required routes.

    7.2.1 Adding the Runner to the Project

    You can have both Apache Camel and Spring Cloud Contract Stub Runner on the classpath. -Remember to annotate your test class with @AutoConfigureStubRunner.

    7.2.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.camel.enabled=false -property.

    Assume that you have the following Maven repository with deployed stubs for the -camelService application:

    └── .m2
    -    └── repository
    -        └── io
    -            └── codearte
    -                └── accurest
    -                    └── stubs
    -                        └── camelService
    -                            ├── 0.0.1-SNAPSHOT
    -                            │   ├── camelService-0.0.1-SNAPSHOT.pom
    -                            │   ├── camelService-0.0.1-SNAPSHOT-stubs.jar
    -                            │   └── maven-metadata-local.xml
    -                            └── maven-metadata-local.xml

    Further assume that the stubs contain the following structure:

    ├── META-INF
    -│   └── MANIFEST.MF
    -└── repository
    -    ├── accurest
    -    │   ├── bookDeleted.groovy
    -    │   ├── bookReturned1.groovy
    -    │   └── bookReturned2.groovy
    -    └── mappings

    Consider the following contracts (numbered 1):

    Contract.make {
    -	label 'return_book_1'
    -	input {
    -		triggeredBy('bookReturnedTriggered()')
    -	}
    -	outputMessage {
    -		sentTo('jms:output')
    -		body('''{ "bookName" : "foo" }''')
    -		headers {
    -			header('BOOK-NAME', 'foo')
    -		}
    -	}
    -}

    Now consider 2

    Contract.make {
    -	label 'return_book_2'
    -	input {
    -		messageFrom('jms:input')
    -		messageBody([
    -				bookName: 'foo'
    -		])
    -		messageHeaders {
    -			header('sample', 'header')
    -		}
    -	}
    -	outputMessage {
    -		sentTo('jms:output')
    -		body([
    -				bookName: 'foo'
    -		])
    -		headers {
    -			header('BOOK-NAME', 'foo')
    -		}
    -	}
    -}

    These examples lend themselves to three scenarios:

    Scenario 1 (no input message)

    To trigger a message via the return_book_1 label, use the StubTigger interface, as -follows:

    stubFinder.trigger('return_book_1')

    To listen to the output of the message sent to jms:output:

    Exchange receivedMessage = camelContext.createConsumerTemplate().receive('jms:output', 5000)

    The received message passes the following assertions:

    receivedMessage != null
    -assertThatBodyContainsBookNameFoo(receivedMessage.in.body)
    -receivedMessage.in.headers.get('BOOK-NAME') == 'foo'

    Scenario 2 (output triggered by input)

    Since the route is set for you, you can send a message to the jms:output -destination:

    camelContext.createProducerTemplate().sendBodyAndHeaders('jms:input', new BookReturned('foo'), [sample: 'header'])

    You can listen to the output of the message sent to jms:output:

    Exchange receivedMessage = camelContext.createConsumerTemplate().receive('jms:output', 5000)

    The received message passes the following assertions:

    receivedMessage != null
    -assertThatBodyContainsBookNameFoo(receivedMessage.in.body)
    -receivedMessage.in.headers.get('BOOK-NAME') == 'foo'

    Scenario 3 (input with no output)

    Since the route is set for you, you can send a message to the jms:output -destination:

    camelContext.createProducerTemplate().sendBodyAndHeaders('jms:delete', new BookReturned('foo'), [sample: 'header'])

    7.3 Stub Runner Integration

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to +or the other in your tests.

    StubTrigger gives you the following options to trigger a message:

    7.1.1 Trigger by Label

    stubFinder.trigger('return_book_1')

    7.1.2 Trigger by Group and Artifact Ids

    stubFinder.trigger('org.springframework.cloud.contract.verifier.stubs:streamService', 'return_book_1')

    7.1.3 Trigger by Artifact Ids

    stubFinder.trigger('streamService', 'return_book_1')

    7.1.4 Trigger All Messages

    stubFinder.trigger()

    7.2 Stub Runner Integration

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to integrate with Spring Integration. For the provided artifacts, it automatically downloads -the stubs and registers the required routes.

    7.3.1 Adding the Runner to the Project

    You can have both Spring Integration and Spring Cloud Contract Stub Runner on the -classpath. Remember to annotate your test class with @AutoConfigureStubRunner.

    7.3.2 Disabling the functionality

    If you need to disable this functionality, set the +the stubs and registers the required routes.

    7.2.1 Adding the Runner to the Project

    You can have both Spring Integration and Spring Cloud Contract Stub Runner on the +classpath. Remember to annotate your test class with @AutoConfigureStubRunner.

    7.2.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.integration.enabled=false property.

    Assume that you have the following Maven repository with deployed stubs for the integrationService application:

    └── .m2
         └── repository
    @@ -2400,7 +2334,7 @@ assertJsons(receivedMessage.payload)
     receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 2 (output triggered by input)

    Since the route is set for you, you can send a message to the output destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'input')

    To listen to the output of the message sent to output:

    Message<?> receivedMessage = messaging.receive('outputTest')

    The received message passes the following assertions:

    receivedMessage != null
     assertJsons(receivedMessage.payload)
    -receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 3 (input with no output)

    Since the route is set for you, you can send a message to the input destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete')

    7.4 Stub Runner Stream

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to +receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 3 (input with no output)

    Since the route is set for you, you can send a message to the input destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete')

    7.3 Stub Runner Stream

    Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to integrate with Spring Stream. For the provided artifacts, it automatically downloads the stubs and registers the required routes.

    [Warning]Warning

    If Stub Runner’s integration with Stream the messageFrom or sentTo Strings are resolved first as a destination of a channel and no such destination exists, the @@ -2413,8 +2347,8 @@ destination is resolved as a channel name.

    </dependency>

    Gradle. 

    testCompile "org.springframework.cloud:spring-cloud-stream-test-support"

    -

    7.4.1 Adding the Runner to the Project

    You can have both Spring Cloud Stream and Spring Cloud Contract Stub Runner on the -classpath. Remember to annotate your test class with @AutoConfigureStubRunner.

    7.4.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.stream.enabled=false +

    7.3.1 Adding the Runner to the Project

    You can have both Spring Cloud Stream and Spring Cloud Contract Stub Runner on the +classpath. Remember to annotate your test class with @AutoConfigureStubRunner.

    7.3.2 Disabling the functionality

    If you need to disable this functionality, set the stubrunner.stream.enabled=false property.

    Assume that you have the following Maven repository with a deployed stubs for the streamService application:

    └── .m2
         └── repository
    @@ -2481,7 +2415,7 @@ receivedMessage.headers.get(destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'bookStorage')

    To listen to the output of the message sent to returnBook:

    Message<?> receivedMessage = messaging.receive('returnBook')

    The received message passes the following assertions:

    receivedMessage != null
     assertJsons(receivedMessage.payload)
     receivedMessage.headers.get('BOOK-NAME') == 'foo'

    Scenario 3 (input with no output)

    Since the route is set for you, you can send a message to the output -destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete')

    7.5 Stub Runner Spring AMQP

    Spring Cloud Contract Verifier Stub Runner’s messaging module provides an easy way to +destination:

    messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete')

    7.4 Stub Runner Spring AMQP

    Spring Cloud Contract Verifier Stub Runner’s messaging module provides an easy way to integrate with Spring AMQP’s Rabbit Template. For the provided artifacts, it automatically downloads the stubs and registers the required routes.

    The integration tries to work standalone (that is, without interaction with a running RabbitMQ message broker). It expects a RabbitTemplate on the application context and @@ -2493,7 +2427,7 @@ queues. Bindings connect an exchange to a queue. If message contracts are trigge Spring AMQP stub runner integration looks for bindings on the application context that match this exchange. Then it collects the queues from the Spring exchanges and tries to find message listeners bound to these queues. The message is triggered for all matching -message listeners.

    7.5.1 Adding the Runner to the Project

    You can have both Spring AMQP and Spring Cloud Contract Stub Runner on the classpath and +message listeners.

    7.4.1 Adding the Runner to the Project

    You can have both Spring AMQP and Spring Cloud Contract Stub Runner on the classpath and set the property stubrunner.amqp.enabled=true. Remember to annotate your test class with @AutoConfigureStubRunner.

    }, { "matchesJsonPath" : "$[?(@.alpha == 'abc')]" }, { - "matchesJsonPath" : "$[?(@.number =~ /(-?\\\\d*(\\\\.\\\\d+)?)/)]" + "matchesJsonPath" : "$[?(@.number =~ /(-?(\\\\d*\\\\.\\\\d+|\\\\d+))/)]" }, { "matchesJsonPath" : "$[?(@.aBoolean =~ /((true|false))/)]" }, { @@ -3625,7 +3559,7 @@ socket.

    Consider the following contract:

    or
     	}
     }

    The following example shows how to set up a base class and Rest Assured:

    import io.restassured.RestAssured;
     import org.junit.Before;
    -import org.springframework.boot.context.embedded.LocalServerPort;
    +import org.springframework.boot.web.server.LocalServerPort;
     import org.springframework.boot.test.context.SpringBootTest;
     
     @SpringBootTest(classes = ContextPathTestingBaseClass.class, webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
    @@ -4476,7 +4410,7 @@ implementation that downloads stubs from a remote repository is used. If you do
     provide these values, the ClasspathStubProvider (which will scan the classpath) is
     used. If you provide more than one, then the first one on the list is used.

    [Important]Important

    If you already have Stream and Integration on the classpath, you need to disable them explicitly by setting the stubrunner.stream.enabled=false and @@ -2924,7 +2858,7 @@ the provided regular expression. The following code shows an example:

    Spring Cloud Contract comes with a series of predefined regular expressions that you can use in your contracts, as shown in the following example:

    protected static final Pattern TRUE_OR_FALSE = Pattern.compile(/(true|false)/)
     protected static final Pattern ONLY_ALPHA_UNICODE = Pattern.compile(/[\p{L}]*/)
    -protected static final Pattern NUMBER = Pattern.compile('-?\\d*(\\.\\d+)?')
    +protected static final Pattern NUMBER = Pattern.compile('-?(\\d*\\.\\d+|\\d+)')
     protected static final Pattern IP_ADDRESS = Pattern.compile('([01]?\\d\\d?|2[0-4]\\d|25[0-5])\\.([01]?\\d\\d?|2[0-4]\\d|25[0-5])\\.([01]?\\d\\d?|2[0-4]\\d|25[0-5])\\.([01]?\\d\\d?|2[0-4]\\d|25[0-5])')
     protected static final Pattern HOSTNAME_PATTERN = Pattern.compile('((http[s]?|ftp):/)/?([^:/\\s]+)(:[0-9]{1,5})?')
     protected static final Pattern EMAIL = Pattern.compile('[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,6}')
    @@ -2941,60 +2875,60 @@ use in your contracts, as shown in the following example:

    return Pattern.compile(values.collect({"^$it\$"}).join("|"))
     }
     
    -String onlyAlphaUnicode() {
    -	return ONLY_ALPHA_UNICODE.pattern()
    +Pattern onlyAlphaUnicode() {
    +	return ONLY_ALPHA_UNICODE
     }
     
    -String number() {
    -	return NUMBER.pattern()
    +Pattern number() {
    +	return NUMBER
     }
     
    -String anyBoolean() {
    -	return TRUE_OR_FALSE.pattern()
    +Pattern anyBoolean() {
    +	return TRUE_OR_FALSE
     }
     
    -String ipAddress() {
    -	return IP_ADDRESS.pattern()
    +Pattern ipAddress() {
    +	return IP_ADDRESS
     }
     
    -String hostname() {
    -	return HOSTNAME_PATTERN.pattern()
    +Pattern hostname() {
    +	return HOSTNAME_PATTERN
     }
     
    -String email() {
    -	return EMAIL.pattern()
    +Pattern email() {
    +	return EMAIL
     }
     
    -String url() {
    -	return URL.pattern()
    +Pattern url() {
    +	return URL
     }
     
    -String uuid(){
    -	return UUID.pattern()
    +Pattern uuid(){
    +	return UUID
     }
     
    -String isoDate() {
    -	return ANY_DATE.pattern()
    +Pattern isoDate() {
    +	return ANY_DATE
     }
     
    -String isoDateTime() {
    -	return ANY_DATE_TIME.pattern()
    +Pattern isoDateTime() {
    +	return ANY_DATE_TIME
     }
     
    -String isoTime() {
    -	return ANY_TIME.pattern()
    +Pattern isoTime() {
    +	return ANY_TIME
     }
     
    -String iso8601WithOffset() {
    -	return ISO8601_WITH_OFFSET.pattern()
    +Pattern iso8601WithOffset() {
    +	return ISO8601_WITH_OFFSET
     }
     
    -String nonEmpty() {
    -	return NON_EMPTY.pattern()
    +Pattern nonEmpty() {
    +	return NON_EMPTY
     }
     
    -String nonBlank() {
    -	return NON_BLANK.pattern()
    +Pattern nonBlank() {
    +	return NON_BLANK
     }

    In your contract, you can use it as shown in the following example:

    Contract dslWithOptionalsInString = Contract.make {
     	priority 1
     	request {
    @@ -3499,7 +3433,7 @@ the method name and passed the proper JSON path as a parameter to it.

    11. Spring Cloud Contract WireMock

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

    If you have a Spring Boot application that uses Tomcat as an embedded server (which is the default with spring-boot-starter-web), you can add spring-cloud-contract-wiremock to your classpath and add @AutoConfigureWireMock in @@ -4536,7 +4470,7 @@ automatic loading of stubs, because they come from the root location in a subdirectory called "mappings". The value of files has no effect on the stubs loaded explicitly from the stubs attribute.

    11.3 Alternative: Using JUnit Rules

    For a more conventional WireMock experience, you can use JUnit @Rules to start and stop the server. To do so, use the WireMockSpring convenience class to obtain an Options -instance, as shown in the followin example:

    @RunWith(SpringRunner.class)
    +instance, as shown in the following example:

    @RunWith(SpringRunner.class)
     @SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
     public class WiremockForDocsClassRuleTests {
     
    @@ -4844,7 +4778,8 @@ you manually set versions of Spring Cloud Contract and the release train
     you might see the following exception:

    Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile (default-testCompile) on project some-project: Compilation failure: Compilation failure:
     [ERROR] /some/path/SomeClass.java:[4,39] package com.jayway.restassured.response does not exist

    This exception will occur due to the fact that the tests got generated with an old version of plugin and at test execution time you have an incompatible -version of the release train (and vice versa).

    Done via issue 267

    13. Links

    The following links may be helpful when working with Spring Cloud Contract Verifier:

    12.3 1.2.x → 2.0.x

    12.3.1 No Camel support

    We will add back Apache Camel support only after this issue +gets fixed

    13. Links

    The following links may be helpful when working with Spring Cloud Contract Verifier:

  • User Property: contractsPath

  • +

    contractsRepositoryPassword:

    + +
    The password to be used to connect to the repo with contracts.
    + +
      + +
    • Type: java.lang.String
    • + +
    • Required: No
    • + +
    • User Property: contractsRepositoryPassword
    • +

    +

    contractsRepositoryProxyHost:

    + +
    The proxy host to be used to connect to the repo with contracts.
    + +
      + +
    • Type: java.lang.String
    • + +
    • Required: No
    • + +
    • User Property: contractsRepositoryProxyHost
    • +

    +

    contractsRepositoryProxyPort:

    + +
    The proxy port to be used to connect to the repo with contracts.
    + +
      + +
    • Type: java.lang.Integer
    • + +
    • Required: No
    • + +
    • User Property: contractsRepositoryProxyPort
    • +

    contractsRepositoryUrl:

    The URL from which a JAR containing the contracts should get @@ -692,6 +772,18 @@ taken into consideration
  • User Property: contractsRepositoryUrl

  • +

    contractsRepositoryUsername:

    + +
    The user name to be used to connect to the repo with contracts.
    + +
      + +
    • Type: java.lang.String
    • + +
    • Required: No
    • + +
    • User Property: contractsRepositoryUsername
    • +

    contractsWorkOffline:

    If true then JAR with contracts will be taken from diff --git a/spring-cloud-contract-maven-plugin/help-mojo.html b/spring-cloud-contract-maven-plugin/help-mojo.html index 0b65c56638..c84451b3f0 100644 --- a/spring-cloud-contract-maven-plugin/help-mojo.html +++ b/spring-cloud-contract-maven-plugin/help-mojo.html @@ -1,13 +1,13 @@ - + Spring Cloud Contract Maven Plugin – spring-cloud-contract:help @@ -146,10 +146,10 @@