Skip to content

Spring Cloud Contract 4.0 Migration Guide

Jump to bottom
Marcin Grzejszczak edited this page Nov 18, 2022 · 3 revisions

In this doc you will be able to find the migration guide on how to migrate to Spring Cloud Contract 4.0.

Spring Cloud Contract 4.0.0-RC3

  • Remove Gradle's src/test/resources/contracts checking
    • Rationale: We've got a separate source set for contract tests: contractTest. We've deprecated searching for the src/test/resources/contracts a long time ago and now it's time to remove this check.
    • Migration path: Either move your contracts from src/test/resources/contracts to src/contractTest/resources/contracts or set contracts { contractsDslDir = file("src/test/resources/contracts") } in your DSL

Spring Cloud Contract 4.0.0-RC2

Leave only code input triggers and output message type

Related issues: Leave only code input triggers and output message type and #1837

Rationale

Until now we had 3 messaging contract types. Output triggered by code execution, Output triggered by an input message and Input message that doesn't produce an output. Effectively we can compare it to Supplier, Function and Consumer interfaces. Truth be told that only the 1st model (Supplier) makes sense. Function is effectively a Supplier + Consumer. A Consumer however is a Stub Runner trigger execution for Supplier contract. So we've decided it's high time to remove 2 other types and leave only one, which simplifies things.

Migration path

Functiontype messaging contract: Convert the contract into aSupplier` version. The input part that you tested previously by sending a message to an actual queue should be converted to triggering of a label from a supplier messaging contract from a producer of that message.

Before:

  • Producer (let's call it A) Application has a message listener on a topic foo and sends a message to a topic bar.
  • Producer contract would contain input section with a messageFrom element and an outputMessage section.
  • The generated test would send a message to the input.messageFrom section and poll for a message on the outputMessage.sentTo destination

After:

If Producer A has a message listener on a topic foo that means that

  • Producer A is in fact both a consumer and a producer
  • Since it's a consumer, then there must be a Producer B that sends a message to foo

Producer A contract would contain triggeredBy section that would execute some code that would in effect trigger message sending as described in the outputMessage section of the contract. The generated test would trigger the code that would send the message and then poll for a message on the outputMessage.sentTo destination To test the Producer A consumer section you should trigger Producer Bs contract which would send a message to the foo topic

Removing support for mocked AMQP, OOB AMQP and OOB Kafka

Related issue: Removing support for mocked AMQP, OOB AMQP and OOB Kafka

Rationale

For RabbitMQ integration, we've been mocking out using mocks and spies internals of Spring MessageListenerContainer and RabbitTemplate to mimic the broker behaviour. Of course, with time, it turned out that we're not supporting all possible combinations.

For Kafka integration we were using the embedded Kafka that could work in a different way than the actual Kafka broker.

Mocking these brokers couldn't be continued in this way - it's unsupportable and doesn't really test the actual communication. This is why we've decided to go with the middleware based approach which means that you should use tools like Testcontainers to start a broker and assert your tests against that broker.

Migration path

Before:

You were using the stubbed AMQP or Kafka Stub Runner features.

After:

  • You need to set up your broker for the tests (e.g. via Testcontainers)
  • You need to setup the MesssageVerifierSender (consumer) or MessageVerifierReceiver (producer) beans where you will define how you are actually sending and receiving messages

Examples:

Migration Guides

Clone this wiki locally