Messaging routes if you’re using one. We’re integrating with Spring Integration, Spring Cloud Stream and Apache Camel. You can however set your own integrations if you want to
+Messaging routes if you’re using one. We’re integrating with Spring Integration, Spring Cloud Stream, Spring AMQP and Apache Camel. You can however set your own integrations if you want to
Acceptance tests (in JUnit or Spock) used to verify if server-side implementation of the API is compliant with the contract (server tests). @@ -3278,7 +3290,7 @@ All of our integrations are working with Spring but you can also create one your
You can use one of the three integration configurations:
+You can use one of the four integration configurations:
Spring Cloud Stream
Spring AMQP
+Apache Camel
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.
+Thus it can use the mockito spy functionality to verify and introspect messages sent by the application.
|
+ Important
+ |
+
+In the current status of the implementation tries to find a MessageListenerAdapter on the application context to send messages into the application, because we want to avoid interacting with a running bus.
+Using annotation driven listener endpoints (e.g. @RabbitListener annotated listener methods) is currently not supported.
+ |
+
It’s enough to have both Spring AMQP and Spring Cloud Contract Stub Runner on classpath.
+Remember to annotate your test class with @AutoConfigureMessageVerifier.
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
+ └── example
+ └── spring-cloud-contract-amqp-test
+ ├── 0.4.0-SNAPSHOT
+ │ ├── spring-cloud-contract-amqp-test-0.4.0-SNAPSHOT.pom
+ │ ├── spring-cloud-contract-amqp-test-0.4.0-SNAPSHOT-stubs.jar
+ │ └── maven-metadata-local.xml
+ └── maven-metadata-local.xmlAnd the stubs contain the following structure:
+├── META-INF
+│ └── MANIFEST.MF
+└── contracts
+ └── shouldProduceValidPersonData.groovyLet’s consider the following contract:
+Contract.make {
+ // Human readable description
+ description 'Should produce valid person data'
+ // Label by means of which the output message can be triggered
+ label 'contract-test.person.created.event'
+ // input to the contract
+ input {
+ // the contract will be triggered by a method
+ triggeredBy('createPerson()')
+ }
+ // output message of the contract
+ outputMessage {
+ // destination to which the output message will be sent
+ sentTo 'contract-test.exchange'
+ headers {
+ header('contentType': 'application/json')
+ header('__TypeId__': 'org.springframework.cloud.contract.stubrunner.messaging.amqp.Person')
+ }
+ // the body of the output message
+ body ([
+ id: $(consumer(9), producer(regex("[0-9]+"))),
+ name: "me"
+ ])
+ }
+}and the following Spring configuration:
+stubrunner.repositoryRoot: classpath:m2repo/repository/
+stubrunner.ids: org.springframework.cloud.contract.verifier.stubs.amqp:spring-cloud-contract-amqp-test:0.4.0-SNAPSHOT:stubsSo to trigger a message using the contract above we’ll use the StubTrigger interface as follows.
stubTrigger.trigger("contract-test.person.created.event")In order to avoid that Spring AMQP is trying to connect to a running broker during our tests we configure a mock ConnectionFactory.
To disable the mocked ConnectionFactory set the property verifier.amqp.mockConnection=false
verifier:
+ amqp:
+ mockConnection: false