Spring Cloud Contract Verifier Messaging

Spring Cloud Contract Verifier lets you verify applications that use messaging as a means of communication. All of the integrations shown in this document work with Spring, but you can also create one of your own and use that.

Integrations

You can use one of the following four integration configurations:

Apache Camel
Spring Integration
Spring Cloud Stream
Spring AMQP

Since we use Spring Boot, if you have added one of these libraries to the classpath, all the messaging configuration is automatically set up.

Remember to put @AutoConfigureMessageVerifier on the base class of your generated tests. Otherwise, messaging part of Spring Cloud Contract Verifier does not work.

If you want to use Spring Cloud Stream, remember to add a dependency on org.springframework.cloud:spring-cloud-stream-test-support, as shown here:

Maven

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-stream-test-support</artifactId>
    <scope>test</scope>
</dependency>

Gradle

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

Manual Integration Testing

The main interface used by the tests is org.springframework.cloud.contract.verifier.messaging.MessageVerifier. It defines how to send and receive messages. You can create your own implementation to achieve the same goal.

In a test, you can inject a ContractVerifierMessageExchange to send and receive messages that follow the contract. Then add @AutoConfigureMessageVerifier to your test. Here’s an example:

@RunWith(SpringTestRunner.class)
@SpringBootTest
@AutoConfigureMessageVerifier
public static class MessagingContractTests {

  @Autowired
  private MessageVerifier verifier;
  ...
}

If your tests require stubs as well, then @AutoConfigureStubRunner includes the messaging configuration, so you only need the one annotation.

Publisher-Side Test Generation

Having the input or outputMessage sections in your DSL results in creation of tests on the publisher’s side. By default, JUnit 4 tests are created. However, there is also a possibility to create JUnit 5, TestNG or Spock tests.

There are 3 main scenarios that we should take into consideration:

Scenario 1: There is no input message that produces an output message. The output message is triggered by a component inside the application (for example, scheduler).
Scenario 2: The input message triggers an output message.
Scenario 3: The input message is consumed and there is no output message.

The destination passed to messageFrom or sentTo can have different meanings for different messaging implementations. For Stream and Integration it is first resolved as a destination of a channel. Then, if there is no such destination it is resolved as a channel name. For Camel, that’s a certain component (for example, jms).

Scenario 1: No Input Message

For the given contract:

Groovy DSL

YAML

The following JUnit test is created:

And the following Spock test would be created:

Scenario 2: Output Triggered by Input

For the given contract:

Groovy DSL

YAML

The following JUnit test is created:

And the following Spock test would be created:

Scenario 3: No Output Message

For the given contract:

Groovy DSL

YAML

The following JUnit test is created:

And the following Spock test would be created:

Consumer Stub Generation

Unlike the HTTP part, in messaging, we need to publish the Groovy DSL inside the JAR with a stub. Then it is parsed on the consumer side and proper stubbed routes are created.

For more information, see [stub-runner-for-messaging] section.

Maven

Gradle