diff --git a/2.0.x/multi/multi__migrations.html b/2.0.x/multi/multi__migrations.html index 1ad50d32d7..acfcfaa6a0 100644 --- a/2.0.x/multi/multi__migrations.html +++ b/2.0.x/multi/multi__migrations.html @@ -82,4 +82,5 @@ all mappings available in a single HttpServerStub. issue 355.

11.2.2 New packages for generated tests

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

Related to issue 260.

11.2.3 New methods in TemplateProcessor

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

Related to -issue 388.

Prev   Next
10. Spring Cloud Contract WireMock Home 12. Links
\ No newline at end of file +issue 388.

11.3 1.2.x → 2.0.x

11.3.1 No Camel support

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

Prev   Next
10. Spring Cloud Contract WireMock Home 12. Links
\ No newline at end of file diff --git a/2.0.x/multi/multi__spring_cloud_contract_stub_runner.html b/2.0.x/multi/multi__spring_cloud_contract_stub_runner.html index d9680f946f..3e88c40b53 100644 --- a/2.0.x/multi/multi__spring_cloud_contract_stub_runner.html +++ b/2.0.x/multi/multi__spring_cloud_contract_stub_runner.html @@ -374,7 +374,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
@@ -456,8 +455,6 @@ its methods as presented below:
DiscoveryClient directly, to call those stubbed
   consul.enabled: false
 eureka.client.enabled: false
 stubrunner:
-  camel.enabled: false
   idsToServiceIds:
     ivyNotation: someValueInsideYourCode
     fraudDetectionServer: someNameThatShouldMapFraudDetectionServer
Test profiles and service discovery
In your integration tests you typically don’t want to call neither a discovery service (e.g. Eureka)
diff --git a/2.0.x/multi/multi__stub_runner_for_messaging.html b/2.0.x/multi/multi__stub_runner_for_messaging.html
index e41cb611d0..d7d607579d 100644
--- a/2.0.x/multi/multi__stub_runner_for_messaging.html
+++ b/2.0.x/multi/multi__stub_runner_for_messaging.html
@@ -1,6 +1,6 @@
 
       
-   6. Stub Runner for Messaging
6. Stub Runner for Messaging
Prev   Next
6. Stub Runner for Messaging
Stub Runner has the functionality to run the published stubs in memory. It can integrate with the following frameworks out of the box
  • Spring Integration
  • Spring Cloud Stream
  • Apache Camel
  • Spring AMQP
It also provides points of entry to integrate with any other solution on the market.
[Important]Important
If you have multiple frameworks on the classpath Stub Runner will need to
+   6. Stub Runner for Messaging
6. Stub Runner for Messaging
Prev   Next
6. Stub Runner for Messaging
Stub Runner has the functionality to run the published stubs in memory. It can integrate with the following frameworks out of the box
  • Spring Integration
  • Spring Cloud Stream
  • Spring AMQP
It also provides points of entry 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.
6.1 Stub triggering
To trigger a message it’s enough to use the StubTrigger interface:
package org.springframework.cloud.contract.stubrunner;
@@ -43,68 +43,10 @@ That way the only remaining framework is Spring AMQP.

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

For convenience the StubFinder interface extends StubTrigger so it’s enough to use only one in your tests.

StubTrigger gives you the following options to trigger a message:

6.1.1 Trigger by label

stubFinder.trigger('return_book_1')

6.1.2 Trigger by group and artifact ids

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

6.1.3 Trigger by artifact ids

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

6.1.4 Trigger all messages

stubFinder.trigger()

6.2 Stub Runner Camel

Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to integrate with Apache Camel. +}

For convenience the StubFinder interface extends StubTrigger so it’s enough to use only one in your tests.

StubTrigger gives you the following options to trigger a message:

6.1.1 Trigger by label

stubFinder.trigger('return_book_1')

6.1.2 Trigger by group and artifact ids

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

6.1.3 Trigger by artifact ids

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

6.1.4 Trigger all messages

stubFinder.trigger()

6.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 will automatically download the stubs and register the required -routes.

6.2.1 Adding it to the project

It’s enough to have both Apache Camel and Spring Cloud Contract Stub Runner on classpath. -Remember to annotate your test class with @AutoConfigureStubRunner.

6.2.2 Disabling the functionality

If you need to disable this functionality just pass stubrunner.camel.enabled=false property.

6.2.3 Examples

Stubs structure

Let us assume that we have the following Maven repository with a 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

And the stubs contain the following structure:

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

Let’s consider the following contracts (let' number it with 1):

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

and number 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')
-		}
-	}
-}

Scenario 1 (no input message)

So as to trigger a message via the return_book_1 label we’ll use the StubTigger interface as follows

stubFinder.trigger('return_book_1')

Next we’ll want to listen to the output of the message sent to jms:output

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

And the received message would pass 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 it’s enough to just send a message to the jms:output destination.

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

Next we’ll want to listen to the output of the message sent to jms:output

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

And the received message would pass 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 it’s enough to just send a message to the jms:output destination.

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

6.3 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 will automatically download the stubs and register the required -routes.

6.3.1 Adding it to the project

It’s enough to have both Spring Integration and Spring Cloud Contract Stub Runner on classpath. -Remember to annotate your test class with @AutoConfigureStubRunner.

6.3.2 Disabling the functionality

If you need to disable this functionality just pass stubrunner.integration.enabled=false property.

6.3.3 Examples

Stubs structure

Let us assume that we have the following Maven repository with a deployed stubs for the +routes.

6.2.1 Adding it to the project

It’s enough to have both Spring Integration and Spring Cloud Contract Stub Runner on classpath. +Remember to annotate your test class with @AutoConfigureStubRunner.

6.2.2 Disabling the functionality

If you need to disable this functionality just pass stubrunner.integration.enabled=false property.

6.2.3 Examples

Stubs structure

Let us assume that we have the following Maven repository with a deployed stubs for the integrationService application.

└── .m2
     └── repository
         └── io
@@ -173,11 +115,11 @@ Remember to annotate your test class with @AutoConfigureSt
 		<queue/>
 	</channel>
 
-</beans:beans>

Scenario 1 (no input message)

So as to trigger a message via the return_book_1 label we’ll use the StubTigger interface as follows

stubFinder.trigger('return_book_1')

Next we’ll want to listen to the output of the message sent to output

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

And the received message would pass the following assertions

receivedMessage != null
+</beans:beans>

Scenario 1 (no input message)

So as to trigger a message via the return_book_1 label we’ll use the StubTigger interface as follows

stubFinder.trigger('return_book_1')

Next we’ll want to listen to the output of the message sent to output

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

And the received message would pass the following assertions

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

Scenario 2 (output triggered by input)

Since the route is set for you it’s enough to just send a message to the output destination.

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

Next we’ll want to listen to the output of the message sent to output

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

And the received message would pass the following assertions

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

Scenario 2 (output triggered by input)

Since the route is set for you it’s enough to just send a message to the output destination.

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

Next we’ll want to listen to the output of the message sent to output

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

And the received message would pass 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 it’s enough to just send a message to the input destination.

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

6.4 Stub Runner Stream

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

Scenario 3 (input with no output)

Since the route is set for you it’s enough to just send a message to the input destination.

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

6.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 will automatically download the stubs and register the required routes.

[Warning]Warning

In Stub Runner’s integration with Stream the messageFrom or sentTo Strings are resolved first as a destination of a channel, and then if there is no such destination it’s resolved as a @@ -190,8 +132,8 @@ channel name.

</dependency>

Gradle.  

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

-

6.4.1 Adding it to the project

It’s enough to have both Spring Cloud Stream and Spring Cloud Contract Stub Runner on classpath. -Remember to annotate your test class with @AutoConfigureStubRunner.

6.4.2 Disabling the functionality

If you need to disable this functionality just pass stubrunner.stream.enabled=false property.

6.4.3 Examples

Stubs structure

Let us assume that we have the following Maven repository with a deployed stubs for the +

6.3.1 Adding it to the project

It’s enough to have both Spring Cloud Stream and Spring Cloud Contract Stub Runner on classpath. +Remember to annotate your test class with @AutoConfigureStubRunner.

6.3.2 Disabling the functionality

If you need to disable this functionality just pass stubrunner.stream.enabled=false property.

6.3.3 Examples

Stubs structure

Let us assume that we have the following Maven repository with a deployed stubs for the streamService application.

└── .m2
     └── repository
         └── io
@@ -249,11 +191,11 @@ Remember to annotate your test class with @AutoConfigureSt
 server:
   port: 0
 
-debug: true

Scenario 1 (no input message)

So as to trigger a message via the return_book_1 label we’ll use the StubTrigger interface as follows

stubFinder.trigger('return_book_1')

Next we’ll want to listen to the output of the message sent to a channel whose destination is returnBook

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

And the received message would pass the following assertions

receivedMessage != null
+debug: true

Scenario 1 (no input message)

So as to trigger a message via the return_book_1 label we’ll use the StubTrigger interface as follows

stubFinder.trigger('return_book_1')

Next we’ll want to listen to the output of the message sent to a channel whose destination is returnBook

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

And the received message would pass the following assertions

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

Scenario 2 (output triggered by input)

Since the route is set for you it’s enough to just send a message to the bookStorage destination.

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

Next we’ll want to listen to the output of the message sent to returnBook

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

And the received message would pass the following assertions

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

Scenario 2 (output triggered by input)

Since the route is set for you it’s enough to just send a message to the bookStorage destination.

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

Next we’ll want to listen to the output of the message sent to returnBook

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

And the received message would pass 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 it’s enough to just send a message to the output destination.

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

6.5 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. +receivedMessage.headers.get('BOOK-NAME') == 'foo'

Scenario 3 (input with no output)

Since the route is set for you it’s enough to just send a message to the output destination.

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

6.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 will automatically download the stubs and register 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 uses it as a spring boot test @SpyBean. @@ -261,10 +203,10 @@ Thus it can use the mockito spy functionality to verify and introspect messages Message listeners on the other side are bound to queues. Bindings connect an exchange to a queue. If message contracts are triggered the Spring AMQP stub runner integration will look for bindings on the application context that match this exchange. Then it collects the queues from the Spring exchanges and tries to find messages listeners bound to these queues. -The message is triggered to all matching message listeners.

6.5.1 Adding it to the project

It’s enough to have both Spring AMQP and Spring Cloud Contract Stub Runner on the classpath and set the property stubrunner.amqp.enabled=true. +The message is triggered to all matching message listeners.

6.4.1 Adding it to the project

It’s enough to 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 via stubrunner.stream.enabled=false and stubrunner.integration.enabled=false -properties

6.5.2 Examples

Stubs structure

Let us assume that we have the following Maven repository with a deployed stubs for the +properties

6.4.2 Examples

Stubs structure

Let us assume that we have the following Maven repository with a deployed stubs for the spring-cloud-contract-amqp-test application.

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

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

\ No newline at end of file
diff --git a/2.0.x/single/spring-cloud-contract.html b/2.0.x/single/spring-cloud-contract.html
index 9c3717d4e0..065067d335 100644
--- a/2.0.x/single/spring-cloud-contract.html
+++ b/2.0.x/single/spring-cloud-contract.html
@@ -1,6 +1,6 @@
 
       
-   Spring Cloud Contract
Spring Cloud Contract
Table of Contents
1. Spring Cloud Contract
2. Spring Cloud Contract Verifier Introduction
2.1. Why?
2.1.1. Testing issues
2.2. Purposes
2.3. How
2.3.1. Define the contract
2.3.2. Client Side
2.3.3. Server Side
2.4. Step by step guide to CDC
2.4.1. Technical note
2.4.2. Consumer side (Loan Issuance)
2.4.3. Producer side (Fraud Detection server)
2.4.4. Consumer side (Loan Issuance) final step
2.5. Dependencies
2.6. Additional links
2.6.1. Spring Cloud Contract video
2.6.2. Readings
2.7. Samples
3. Spring Cloud Contract Verifier Setup
3.1. Gradle Project
3.1.1. Prerequisites
3.1.2. Add gradle plugin with dependencies
3.1.3. Gradle and Rest Assured 2.0
3.1.4. Snapshot versions for Gradle
3.1.5. Add stubs
3.1.6. Run plugin
3.1.7. Default setup
3.1.8. Configure plugin
3.1.9. Configuration options
3.1.10. Single base class for all tests
3.1.11. Different base classes for contracts
3.1.12. Invoking generated tests
3.1.13. Spring Cloud Contract Verifier on consumer side
3.2. Using in your Maven project
3.2.1. Add maven plugin
3.2.2. Maven and Rest Assured 2.0
3.2.3. Snapshot versions for Maven
3.2.4. Add stubs
3.2.5. Run plugin
3.2.6. Configure plugin
3.2.7. Important configuration options
3.2.8. Single base class for all tests
3.2.9. Different base classes for contracts
3.2.10. Invoking generated tests
3.2.11. FAQ with Maven Plugin
3.2.12. Maven Plugin and STS
3.2.13. Spring Cloud Contract Verifier on consumer side
3.3. Scenarios
3.4. Stubs and transitive dependencies
4. Spring Cloud Contract Verifier Messaging
4.1. Integrations
4.2. Manual Integration Testing
4.3. Publisher side test generation
4.3.1. Scenario 1 (no input message)
4.3.2. Scenario 2 (output triggered by input)
4.3.3. Scenario 3 (no output message)
4.4. Consumer Stub Side generation
5. Spring Cloud Contract Stub Runner
5.1. Snapshot versions
5.2. Publishing stubs as JARs
5.3. Stub Runner Core
5.3.1. Retrieving stubs
Stub downloading
Classpath scanning
5.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
5.4. Stub Runner JUnit Rule
5.4.1. Maven settings
5.4.2. Providing fixed ports
5.4.3. Fluent API
5.4.4. Stub Runner with Spring
5.5. Stub Runner Spring Cloud
5.5.1. Stubbing Service Discovery
Test profiles and service discovery
5.5.2. Additional Configuration
5.6. Stub Runner Boot Application
5.6.1. How to use it?
Stub Runner Server
Spring Cloud CLI
5.6.2. Endpoints
HTTP
Messaging
5.6.3. Example
5.6.4. Stub Runner Boot with Service Discovery
5.7. Stubs Per Consumer
5.8. Common
5.8.1. Common properties for JUnit and Spring
5.8.2. Stub runner stubs ids
6. Stub Runner for Messaging
6.1. Stub triggering
6.1.1. Trigger by label
6.1.2. Trigger by group and artifact ids
6.1.3. Trigger by artifact ids
6.1.4. Trigger all messages
6.2. Stub Runner Camel
6.2.1. Adding it to the project
6.2.2. Disabling the functionality
6.2.3. Examples
Stubs structure
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.3. Stub Runner Integration
6.3.1. Adding it to the project
6.3.2. Disabling the functionality
6.3.3. Examples
Stubs structure
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.4. Stub Runner Stream
6.4.1. Adding it to the project
6.4.2. Disabling the functionality
6.4.3. Examples
Stubs structure
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.5. Stub Runner Spring AMQP
6.5.1. Adding it to the project
6.5.2. Examples
Stubs structure
Triggering the message
Spring AMQP Test Configuration
7. Contract DSL
7.1. Limitations
7.2. Common Top-Level elements
7.2.1. Description
7.2.2. Name
7.2.3. Ignoring contracts
7.2.4. Passing values from files
7.2.5. HTTP Top-Level Elements
7.3. Request
7.4. Response
7.5. Dynamic properties
7.5.1. Dynamic properties inside the body
7.5.2. Regular expressions
7.5.3. Passing optional parameters
7.5.4. Executing custom methods on server side
7.5.5. Referencing request from response
7.5.6. Dynamic properties in matchers sections
7.6. JAX-RS support
7.7. Async support
7.8. Working with Context Paths
7.9. Messaging Top-Level Elements
7.9.1. Output triggered by a method
7.9.2. Output triggered by a message
7.9.3. Consumer / Producer
7.10. Multiple contracts in one file
8. Customization
8.1. Extending the DSL
8.1.1. Common JAR
8.1.2. Adding the dependency to project
8.1.3. Test dependency in project’s dependencies
8.1.4. Test dependency in plugin’s dependencies
8.1.5. Referencing classes in DSLs
9. Pluggable architecture
9.1. Custom contract converter
9.1.1. Pact converter
9.1.2. Pact contract
9.1.3. Pact for producers
9.1.4. Pact for consumers
9.2. Custom test generator
9.3. Custom stub generator
9.4. Custom Stub Runner
9.5. Custom Stub Downloader
10. Spring Cloud Contract WireMock
10.1. Registering Stubs Automatically
10.2. Using Files to Specify the Stub Bodies
10.3. Alternative: Using JUnit Rules
10.4. Relaxed SSL Validation for Rest Template
10.5. WireMock and Spring MVC Mocks
10.6. Generating Stubs using RestDocs
10.7. Generating Contracts using RestDocs
11. Migrations
11.1. 1.0.x → 1.1.x
11.1.1. New structure of generated stubs
11.2. 1.1.x → 1.2.x
11.2.1. Custom HttpServerStub
11.2.2. New packages for generated tests
11.2.3. New methods in TemplateProcessor
12. Links
Documentation Authors: Adam Dudczak, Mathias Düsterhöft, Marcin Grzejszczak, Dennis Kieselhorst, Jakub Kubryński, Karol Lassak,
+   Spring Cloud Contract
Spring Cloud Contract
Table of Contents
1. Spring Cloud Contract
2. Spring Cloud Contract Verifier Introduction
2.1. Why?
2.1.1. Testing issues
2.2. Purposes
2.3. How
2.3.1. Define the contract
2.3.2. Client Side
2.3.3. Server Side
2.4. Step by step guide to CDC
2.4.1. Technical note
2.4.2. Consumer side (Loan Issuance)
2.4.3. Producer side (Fraud Detection server)
2.4.4. Consumer side (Loan Issuance) final step
2.5. Dependencies
2.6. Additional links
2.6.1. Spring Cloud Contract video
2.6.2. Readings
2.7. Samples
3. Spring Cloud Contract Verifier Setup
3.1. Gradle Project
3.1.1. Prerequisites
3.1.2. Add gradle plugin with dependencies
3.1.3. Gradle and Rest Assured 2.0
3.1.4. Snapshot versions for Gradle
3.1.5. Add stubs
3.1.6. Run plugin
3.1.7. Default setup
3.1.8. Configure plugin
3.1.9. Configuration options
3.1.10. Single base class for all tests
3.1.11. Different base classes for contracts
3.1.12. Invoking generated tests
3.1.13. Spring Cloud Contract Verifier on consumer side
3.2. Using in your Maven project
3.2.1. Add maven plugin
3.2.2. Maven and Rest Assured 2.0
3.2.3. Snapshot versions for Maven
3.2.4. Add stubs
3.2.5. Run plugin
3.2.6. Configure plugin
3.2.7. Important configuration options
3.2.8. Single base class for all tests
3.2.9. Different base classes for contracts
3.2.10. Invoking generated tests
3.2.11. FAQ with Maven Plugin
3.2.12. Maven Plugin and STS
3.2.13. Spring Cloud Contract Verifier on consumer side
3.3. Scenarios
3.4. Stubs and transitive dependencies
4. Spring Cloud Contract Verifier Messaging
4.1. Integrations
4.2. Manual Integration Testing
4.3. Publisher side test generation
4.3.1. Scenario 1 (no input message)
4.3.2. Scenario 2 (output triggered by input)
4.3.3. Scenario 3 (no output message)
4.4. Consumer Stub Side generation
5. Spring Cloud Contract Stub Runner
5.1. Snapshot versions
5.2. Publishing stubs as JARs
5.3. Stub Runner Core
5.3.1. Retrieving stubs
Stub downloading
Classpath scanning
5.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
5.4. Stub Runner JUnit Rule
5.4.1. Maven settings
5.4.2. Providing fixed ports
5.4.3. Fluent API
5.4.4. Stub Runner with Spring
5.5. Stub Runner Spring Cloud
5.5.1. Stubbing Service Discovery
Test profiles and service discovery
5.5.2. Additional Configuration
5.6. Stub Runner Boot Application
5.6.1. How to use it?
Stub Runner Server
Spring Cloud CLI
5.6.2. Endpoints
HTTP
Messaging
5.6.3. Example
5.6.4. Stub Runner Boot with Service Discovery
5.7. Stubs Per Consumer
5.8. Common
5.8.1. Common properties for JUnit and Spring
5.8.2. Stub runner stubs ids
6. Stub Runner for Messaging
6.1. Stub triggering
6.1.1. Trigger by label
6.1.2. Trigger by group and artifact ids
6.1.3. Trigger by artifact ids
6.1.4. Trigger all messages
6.2. Stub Runner Integration
6.2.1. Adding it to the project
6.2.2. Disabling the functionality
6.2.3. Examples
Stubs structure
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.3. Stub Runner Stream
6.3.1. Adding it to the project
6.3.2. Disabling the functionality
6.3.3. Examples
Stubs structure
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
6.4. Stub Runner Spring AMQP
6.4.1. Adding it to the project
6.4.2. Examples
Stubs structure
Triggering the message
Spring AMQP Test Configuration
7. Contract DSL
7.1. Limitations
7.2. Common Top-Level elements
7.2.1. Description
7.2.2. Name
7.2.3. Ignoring contracts
7.2.4. Passing values from files
7.2.5. HTTP Top-Level Elements
7.3. Request
7.4. Response
7.5. Dynamic properties
7.5.1. Dynamic properties inside the body
7.5.2. Regular expressions
7.5.3. Passing optional parameters
7.5.4. Executing custom methods on server side
7.5.5. Referencing request from response
7.5.6. Dynamic properties in matchers sections
7.6. JAX-RS support
7.7. Async support
7.8. Working with Context Paths
7.9. Messaging Top-Level Elements
7.9.1. Output triggered by a method
7.9.2. Output triggered by a message
7.9.3. Consumer / Producer
7.10. Multiple contracts in one file
8. Customization
8.1. Extending the DSL
8.1.1. Common JAR
8.1.2. Adding the dependency to project
8.1.3. Test dependency in project’s dependencies
8.1.4. Test dependency in plugin’s dependencies
8.1.5. Referencing classes in DSLs
9. Pluggable architecture
9.1. Custom contract converter
9.1.1. Pact converter
9.1.2. Pact contract
9.1.3. Pact for producers
9.1.4. Pact for consumers
9.2. Custom test generator
9.3. Custom stub generator
9.4. Custom Stub Runner
9.5. Custom Stub Downloader
10. Spring Cloud Contract WireMock
10.1. Registering Stubs Automatically
10.2. Using Files to Specify the Stub Bodies
10.3. Alternative: Using JUnit Rules
10.4. Relaxed SSL Validation for Rest Template
10.5. WireMock and Spring MVC Mocks
10.6. Generating Stubs using RestDocs
10.7. Generating Contracts using RestDocs
11. Migrations
11.1. 1.0.x → 1.1.x
11.1.1. New structure of generated stubs
11.2. 1.1.x → 1.2.x
11.2.1. Custom HttpServerStub
11.2.2. New packages for generated tests
11.2.3. New methods in TemplateProcessor
11.3. 1.2.x → 2.0.x
11.3.1. No Camel support
12. Links
Documentation Authors: Adam Dudczak, Mathias Düsterhöft, Marcin Grzejszczak, Dennis Kieselhorst, Jakub Kubryński, Karol Lassak,
 Olga Maciaszek-Sharma, Mariusz Smykuła, Dave Syer
2.0.0.BUILD-SNAPSHOT
1. Spring Cloud Contract
What you always need is confidence in pushing new features into a new application or service in a distributed system.
 This project provides support for Consumer Driven Contracts and service schemas in Spring applications, covering a
 range of options for writing tests, publishing them as assets, asserting that a contract is kept by producers
@@ -1422,7 +1422,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
@@ -1504,8 +1503,6 @@ its methods as presented below:
DiscoveryClient directly, to call those stubbed
   consul.enabled: false
 eureka.client.enabled: false
 stubrunner:
-  camel.enabled: false
   idsToServiceIds:
     ivyNotation: someValueInsideYourCode
     fraudDetectionServer: someNameThatShouldMapFraudDetectionServer
Test profiles and service discovery
In your integration tests you typically don’t want to call neither a discovery service (e.g. Eureka)
@@ -1735,7 +1731,7 @@ transitions from digit to letter and vice versa delimit the version segments. De
 recognized and treated specially: "alpha" = "a" < "beta" = "b" < "milestone" = "m" < "cr" = "rc" < "snapshot" < "final" = "ga" < "sp". All of those well-known qualifiers
 are considered smaller/older than other strings. An empty segment/string is equivalent to 0.
In addition to the above mentioned qualifiers, the tokens "min" and "max" may be used as final version segment to denote the smallest/greatest version having a given prefix.
 For example, "1.2.min" denotes the smallest version in the 1.2 line, "1.2.max" denotes the greatest version in the 1.2 line. A version range of the form "[M.N.*]" is short for "[M.N.min, M.N.max]".
Numbers and strings are considered incomparable against each other. Where version segments of different kind would collide, comparison will instead assume that the previous
-segments are padded with trailing 0 or "ga" segments, respectively, until the kind mismatch is resolved, e.g. "1-alpha" = "1.0.0-alpha" < "1.0.1-ga" = "1.0.1".
6. Stub Runner for Messaging
Stub Runner has the functionality to run the published stubs in memory. It can integrate with the following frameworks out of the box
  • Spring Integration
  • Spring Cloud Stream
  • Apache Camel
  • Spring AMQP
It also provides points of entry to integrate with any other solution on the market.
[Important]Important
If you have multiple frameworks on the classpath Stub Runner will need to
+segments are padded with trailing 0 or "ga" segments, respectively, until the kind mismatch is resolved, e.g. "1-alpha" = "1.0.0-alpha" < "1.0.1-ga" = "1.0.1".
6. Stub Runner for Messaging
Stub Runner has the functionality to run the published stubs in memory. It can integrate with the following frameworks out of the box
  • Spring Integration
  • Spring Cloud Stream
  • Spring AMQP
It also provides points of entry 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.
6.1 Stub triggering
To trigger a message it’s enough to use the StubTrigger interface:
package org.springframework.cloud.contract.stubrunner;
@@ -1778,68 +1774,10 @@ That way the only remaining framework is Spring AMQP.

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

For convenience the StubFinder interface extends StubTrigger so it’s enough to use only one in your tests.

StubTrigger gives you the following options to trigger a message:

6.1.1 Trigger by label

stubFinder.trigger('return_book_1')

6.1.2 Trigger by group and artifact ids

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

6.1.3 Trigger by artifact ids

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

6.1.4 Trigger all messages

stubFinder.trigger()

6.2 Stub Runner Camel

Spring Cloud Contract Verifier Stub Runner’s messaging module gives you an easy way to integrate with Apache Camel. +}

For convenience the StubFinder interface extends StubTrigger so it’s enough to use only one in your tests.

StubTrigger gives you the following options to trigger a message:

6.1.1 Trigger by label

stubFinder.trigger('return_book_1')

6.1.2 Trigger by group and artifact ids

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

6.1.3 Trigger by artifact ids

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

6.1.4 Trigger all messages

stubFinder.trigger()

6.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 will automatically download the stubs and register the required -routes.

6.2.1 Adding it to the project

It’s enough to have both Apache Camel and Spring Cloud Contract Stub Runner on classpath. -Remember to annotate your test class with @AutoConfigureStubRunner.

6.2.2 Disabling the functionality

If you need to disable this functionality just pass stubrunner.camel.enabled=false property.

6.2.3 Examples

Stubs structure

Let us assume that we have the following Maven repository with a 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

And the stubs contain the following structure:

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

Let’s consider the following contracts (let' number it with 1):

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

and number 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')
-		}
-	}
-}

Scenario 1 (no input message)

So as to trigger a message via the return_book_1 label we’ll use the StubTigger interface as follows

stubFinder.trigger('return_book_1')

Next we’ll want to listen to the output of the message sent to jms:output

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

And the received message would pass 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 it’s enough to just send a message to the jms:output destination.

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

Next we’ll want to listen to the output of the message sent to jms:output

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

And the received message would pass 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 it’s enough to just send a message to the jms:output destination.

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

6.3 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 will automatically download the stubs and register the required -routes.

6.3.1 Adding it to the project

It’s enough to have both Spring Integration and Spring Cloud Contract Stub Runner on classpath. -Remember to annotate your test class with @AutoConfigureStubRunner.

6.3.2 Disabling the functionality

If you need to disable this functionality just pass stubrunner.integration.enabled=false property.

6.3.3 Examples

Stubs structure

Let us assume that we have the following Maven repository with a deployed stubs for the +routes.

6.2.1 Adding it to the project

It’s enough to have both Spring Integration and Spring Cloud Contract Stub Runner on classpath. +Remember to annotate your test class with @AutoConfigureStubRunner.

6.2.2 Disabling the functionality

If you need to disable this functionality just pass stubrunner.integration.enabled=false property.

6.2.3 Examples

Stubs structure

Let us assume that we have the following Maven repository with a deployed stubs for the integrationService application.

└── .m2
     └── repository
         └── io
@@ -1908,11 +1846,11 @@ Remember to annotate your test class with @AutoConfigureSt
 		<queue/>
 	</channel>
 
-</beans:beans>

Scenario 1 (no input message)

So as to trigger a message via the return_book_1 label we’ll use the StubTigger interface as follows

stubFinder.trigger('return_book_1')

Next we’ll want to listen to the output of the message sent to output

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

And the received message would pass the following assertions

receivedMessage != null
+</beans:beans>

Scenario 1 (no input message)

So as to trigger a message via the return_book_1 label we’ll use the StubTigger interface as follows

stubFinder.trigger('return_book_1')

Next we’ll want to listen to the output of the message sent to output

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

And the received message would pass the following assertions

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

Scenario 2 (output triggered by input)

Since the route is set for you it’s enough to just send a message to the output destination.

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

Next we’ll want to listen to the output of the message sent to output

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

And the received message would pass the following assertions

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

Scenario 2 (output triggered by input)

Since the route is set for you it’s enough to just send a message to the output destination.

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

Next we’ll want to listen to the output of the message sent to output

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

And the received message would pass 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 it’s enough to just send a message to the input destination.

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

6.4 Stub Runner Stream

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

Scenario 3 (input with no output)

Since the route is set for you it’s enough to just send a message to the input destination.

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

6.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 will automatically download the stubs and register the required routes.

[Warning]Warning

In Stub Runner’s integration with Stream the messageFrom or sentTo Strings are resolved first as a destination of a channel, and then if there is no such destination it’s resolved as a @@ -1925,8 +1863,8 @@ channel name.

</dependency>

Gradle.  

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

-

6.4.1 Adding it to the project

It’s enough to have both Spring Cloud Stream and Spring Cloud Contract Stub Runner on classpath. -Remember to annotate your test class with @AutoConfigureStubRunner.

6.4.2 Disabling the functionality

If you need to disable this functionality just pass stubrunner.stream.enabled=false property.

6.4.3 Examples

Stubs structure

Let us assume that we have the following Maven repository with a deployed stubs for the +

6.3.1 Adding it to the project

It’s enough to have both Spring Cloud Stream and Spring Cloud Contract Stub Runner on classpath. +Remember to annotate your test class with @AutoConfigureStubRunner.

6.3.2 Disabling the functionality

If you need to disable this functionality just pass stubrunner.stream.enabled=false property.

6.3.3 Examples

Stubs structure

Let us assume that we have the following Maven repository with a deployed stubs for the streamService application.

└── .m2
     └── repository
         └── io
@@ -1984,11 +1922,11 @@ Remember to annotate your test class with @AutoConfigureSt
 server:
   port: 0
 
-debug: true

Scenario 1 (no input message)

So as to trigger a message via the return_book_1 label we’ll use the StubTrigger interface as follows

stubFinder.trigger('return_book_1')

Next we’ll want to listen to the output of the message sent to a channel whose destination is returnBook

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

And the received message would pass the following assertions

receivedMessage != null
+debug: true

Scenario 1 (no input message)

So as to trigger a message via the return_book_1 label we’ll use the StubTrigger interface as follows

stubFinder.trigger('return_book_1')

Next we’ll want to listen to the output of the message sent to a channel whose destination is returnBook

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

And the received message would pass the following assertions

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

Scenario 2 (output triggered by input)

Since the route is set for you it’s enough to just send a message to the bookStorage destination.

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

Next we’ll want to listen to the output of the message sent to returnBook

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

And the received message would pass the following assertions

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

Scenario 2 (output triggered by input)

Since the route is set for you it’s enough to just send a message to the bookStorage destination.

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

Next we’ll want to listen to the output of the message sent to returnBook

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

And the received message would pass 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 it’s enough to just send a message to the output destination.

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

6.5 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. +receivedMessage.headers.get('BOOK-NAME') == 'foo'

Scenario 3 (input with no output)

Since the route is set for you it’s enough to just send a message to the output destination.

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

6.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 will automatically download the stubs and register 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 uses it as a spring boot test @SpyBean. @@ -1996,10 +1934,10 @@ Thus it can use the mockito spy functionality to verify and introspect messages Message listeners on the other side are bound to queues. Bindings connect an exchange to a queue. If message contracts are triggered the Spring AMQP stub runner integration will look for bindings on the application context that match this exchange. Then it collects the queues from the Spring exchanges and tries to find messages listeners bound to these queues. -The message is triggered to all matching message listeners.

6.5.1 Adding it to the project

It’s enough to have both Spring AMQP and Spring Cloud Contract Stub Runner on the classpath and set the property stubrunner.amqp.enabled=true. +The message is triggered to all matching message listeners.

6.4.1 Adding it to the project

It’s enough to 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 via stubrunner.stream.enabled=false and stubrunner.integration.enabled=false -properties

6.5.2 Examples

Stubs structure

Let us assume that we have the following Maven repository with a deployed stubs for the +properties

6.4.2 Examples

Stubs structure

Let us assume that we have the following Maven repository with a deployed stubs for the spring-cloud-contract-amqp-test application.

└── .m2
     └── repository
         └── com
@@ -4233,4 +4171,5 @@ all mappings available in a single HttpServerStub.
 issue 355.

11.2.2 New packages for generated tests

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

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

Related to issue 260.

11.2.3 New methods in TemplateProcessor

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

Related to -issue 388.

12. Links

Here you can find interesting links related to Spring Cloud Contract Verifier:

\ No newline at end of file +issue 388.

11.3 1.2.x → 2.0.x

11.3.1 No Camel support

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

12. Links

Here you can find interesting links related to Spring Cloud Contract Verifier:

\ No newline at end of file diff --git a/2.0.x/spring-cloud-contract.xml b/2.0.x/spring-cloud-contract.xml index 97577b333c..ee55e59c9a 100644 --- a/2.0.x/spring-cloud-contract.xml +++ b/2.0.x/spring-cloud-contract.xml @@ -2427,7 +2427,6 @@ and registers in WireMock the selected stubs. 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 @@ -2511,8 +2510,6 @@ class StubRunnerConfigurationSpec extends Specification { - org.springframework.cloud.contract.verifier.stubs:bootService cloud: enabled: false - camel: - enabled: false spring.cloud: consul.enabled: false @@ -2579,7 +2576,6 @@ or DiscoveryClient directly, to call those stubbed servers in consul.enabled: false eureka.client.enabled: false stubrunner: - camel.enabled: false idsToServiceIds: ivyNotation: someValueInsideYourCode fraudDetectionServer: someNameThatShouldMapFraudDetectionServer @@ -3004,9 +3000,6 @@ segments are padded with trailing 0 or "ga" segments, respectively, until the ki Spring Cloud Stream -Apache Camel - - Spring AMQP @@ -3069,141 +3062,34 @@ public interface StubTrigger {
Trigger by group and artifact ids -stubFinder.trigger('org.springframework.cloud.contract.verifier.stubs:camelService', 'return_book_1') +stubFinder.trigger('org.springframework.cloud.contract.verifier.stubs:streamService', 'return_book_1')
Trigger by artifact ids -stubFinder.trigger('camelService', 'return_book_1') +stubFinder.trigger('streamService', 'return_book_1')
Trigger all messages stubFinder.trigger()
-
-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 will automatically download the stubs and register the required -routes. -
-Adding it to the project -It’s enough to have both Apache Camel and Spring Cloud Contract Stub Runner on classpath. -Remember to annotate your test class with @AutoConfigureStubRunner. -
-
-Disabling the functionality -If you need to disable this functionality just pass stubrunner.camel.enabled=false property. -
-
-Examples -
-Stubs structure -Let us assume that we have the following Maven repository with a 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 -And the stubs contain the following structure: -├── META-INF -│   └── MANIFEST.MF -└── repository - ├── accurest - │   ├── bookDeleted.groovy - │   ├── bookReturned1.groovy - │   └── bookReturned2.groovy - └── mappings -Let’s consider the following contracts (let' number it with 1): -Contract.make { - label 'return_book_1' - input { - triggeredBy('bookReturnedTriggered()') - } - outputMessage { - sentTo('jms:output') - body('''{ "bookName" : "foo" }''') - headers { - header('BOOK-NAME', 'foo') - } - } -} -and number 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') - } - } -} -
-
-Scenario 1 (no input message) -So as to trigger a message via the return_book_1 label we’ll use the StubTigger interface as follows -stubFinder.trigger('return_book_1') -Next we’ll want to listen to the output of the message sent to jms:output -Exchange receivedMessage = camelContext.createConsumerTemplate().receive('jms:output', 5000) -And the received message would pass 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 it’s enough to just send a message to the jms:output destination. -camelContext.createProducerTemplate().sendBodyAndHeaders('jms:input', new BookReturned('foo'), [sample: 'header']) -Next we’ll want to listen to the output of the message sent to jms:output -Exchange receivedMessage = camelContext.createConsumerTemplate().receive('jms:output', 5000) -And the received message would pass 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 it’s enough to just send a message to the jms:output destination. -camelContext.createProducerTemplate().sendBodyAndHeaders('jms:delete', new BookReturned('foo'), [sample: 'header']) -
-
-
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 will automatically download the stubs and register the required routes. -
+
Adding it to the project It’s enough to have both Spring Integration and Spring Cloud Contract Stub Runner on classpath. Remember to annotate your test class with @AutoConfigureStubRunner.
-
+
Disabling the functionality If you need to disable this functionality just pass stubrunner.integration.enabled=false property.
-
+
Examples -
+
Stubs structure Let us assume that we have the following Maven repository with a deployed stubs for the integrationService application. @@ -3285,7 +3171,7 @@ Remember to annotate your test class with @AutoConfigureStubRunner
-
+
Scenario 1 (no input message) So as to trigger a message via the return_book_1 label we’ll use the StubTigger interface as follows stubFinder.trigger('return_book_1') @@ -3296,7 +3182,7 @@ Remember to annotate your test class with @AutoConfigureStubRunner
-
+
Scenario 2 (output triggered by input) Since the route is set for you it’s enough to just send a message to the output destination. messaging.send(new BookReturned('foo'), [sample: 'header'], 'input') @@ -3307,7 +3193,7 @@ receivedMessage.headers.get('BOOK-NAME') == 'foo' assertJsons(receivedMessage.payload) receivedMessage.headers.get('BOOK-NAME') == 'foo'
-
+
Scenario 3 (input with no output) Since the route is set for you it’s enough to just send a message to the input destination. messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete') @@ -3344,18 +3230,18 @@ channel name. testCompile "org.springframework.cloud:spring-cloud-stream-test-support" -
+
Adding it to the project It’s enough to have both Spring Cloud Stream and Spring Cloud Contract Stub Runner on classpath. Remember to annotate your test class with @AutoConfigureStubRunner.
-
+
Disabling the functionality If you need to disable this functionality just pass stubrunner.stream.enabled=false property.
-
+
Examples -
+
Stubs structure Let us assume that we have the following Maven repository with a deployed stubs for the streamService application. @@ -3426,7 +3312,7 @@ server: debug: true
-
+
Scenario 1 (no input message) So as to trigger a message via the return_book_1 label we’ll use the StubTrigger interface as follows stubFinder.trigger('return_book_1') @@ -3437,7 +3323,7 @@ debug: true assertJsons(receivedMessage.payload) receivedMessage.headers.get('BOOK-NAME') == 'foo'
-
+
Scenario 2 (output triggered by input) Since the route is set for you it’s enough to just send a message to the bookStorage destination. messaging.send(new BookReturned('foo'), [sample: 'header'], 'bookStorage') @@ -3448,7 +3334,7 @@ receivedMessage.headers.get('BOOK-NAME') == 'foo' assertJsons(receivedMessage.payload) receivedMessage.headers.get('BOOK-NAME') == 'foo'
-
+
Scenario 3 (input with no output) Since the route is set for you it’s enough to just send a message to the output destination. messaging.send(new BookReturned('foo'), [sample: 'header'], 'delete') @@ -3469,7 +3355,7 @@ Message listeners on the other side are bound to queues. Bindings connect an exc If message contracts are triggered the Spring AMQP stub runner integration will look for bindings on the application context that match this exchange. Then it collects the queues from the Spring exchanges and tries to find messages listeners bound to these queues. The message is triggered to all matching message listeners. -
+
Adding it to the project It’s enough to 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. @@ -3479,9 +3365,9 @@ to disable them explicitly via stubrunner.stream.enabled=false
-
+
Examples -
+
Stubs structure Let us assume that we have the following Maven repository with a deployed stubs for the spring-cloud-contract-amqp-test application. @@ -6440,6 +6326,14 @@ all mappings available in a single HttpServerStub. Related to issue 388.
+
+1.2.x → 2.0.x +
+No Camel support +We will add back Apache Camel support only after this issue +gets fixed +
+
Links