When using Spring Cloud Contracts, why is the producer creating the contracts?

1
votes

I have been playing with Spring Cloud Contracts. Here is my understanding of the workflow thus far.

On the server Side

  • Write the contract (in groovy or yaml)
  • Auto generate the tests (using gradle plugin)
  • Setup BaseClass that does appropriate setup setups for the Controller
  • Run the auto generated Tests
  • Publish the stubs jar file that is generated to some local repo (which contains wiremock server built in, with request/responses)

On the client side

  • Download the stub jar file
  • Write tests against this stub jar. Use stubrunner to verify responses

What I fail to understand is how is this Consumer driven? The contracts seems to originate from the producer, the consumer seems to be passively testing what the producer has published (using stubs jar file). A producer could accidentally not update the contracts, but make breaking changes. This can lead to tests on the client passing even though it should have failed. Is this true or have I misunderstood a step where the contracts are created from the consumer side

Thoughts?

1
spring-cloudconsumerspring-cloud-contract
What you're describing is producer, not consumer, driven. If the producer makes breaking changes and the contract isn't updated, it will fail the verification. – jonrsharpe
My confusion is around the workflow, in all the examples I have seen, the producer generates the contract, the consumer is merely executing their tests against this jar file. If the tests fail on the consumer side, is the expectation that the consumer team talks to the producer team and conveys the failure? It doesn't seem to me as Consumer Driven. – Karthik Balasubramanian
Why would that seem consumer driven? It's not; as you say, the producer generates the contract and the producer is merely tested against it. – jonrsharpe
But isnt spring cloud contract supposed to promote Consumer Driven Contract testing? One of the main advantages of CDC is to let the producers know via automated tests, when they are introducing breaking changes. Putting that responsibility on each consumer to ensure that they are compatible with the producer seems to be against CDC (very good chance, I could have gotten CDC wrong, in which case please do correct me) – Karthik Balasubramanian

1 Answers

1
votes

Consumer Driven Contract (CDC) Development is basically a Test Driven Development (TDD) extended to the Producer-Consumer applications. Since it's TDD - tests should come first and then the implementation. And since it's Consumer Driven - the consumer creates tests for the producer.

So let's assume that we a have a Producer and a Consumer and some new feature that needs to be implemented. In CDC the workflow would go as follows (you can find more information in the official documentation).

On the Consumer side:

  • Write the missing implementation for the feature
  • Clone Producer repository locally
  • Define the contract locally in the repository of Producer (and auto-generate unit tests for it)
  • Run the integration tests (on cosumer's side)
  • File a pull request

On the Producer side:

  • Take over the pull request (tests are already generated here by the cosumer)
  • Write the missing implementation (TDD-style)
  • Deploy your app
  • Work online

It all makes sense now since consumer writes contracts for the new feature (but in the producer's repository) - we have a Consumer Driven Approach.