Monday, December 11, 2017

Consumer-driven contract testing

Why CDC ?

When adopting microservice architecture, the system comprises of multiple microservices that makes integration test more difficult.
To verify end-to-end test we can do 1 of the following
  • Deploy all microservices to test
  • Mock other microservices
But both approaches have lots of disadvantages.
The idea of CDC is to have a contract between service producer and consumer, both side will verify again the contract if any changes violate it tests will fail.  

How ?

There are some cool frameworks , Pact is a popular one
Last year Spring cloud contract project started and is gaining attention sine it supports Spring applications well.
Producer side:
  • Define the contracts using Groovy DSL
  • The framework generates tests based on the contracts
  • Implement endpoints to pass tests
  • Generate stub data and upload to a common place for consumers to access ( stubs is packaged as a jar file and can be pushed to central Maven repo )
Consumer side:
  • Get stub data from producer
  • A WireMock instance will start with the stub data
  • Execute tests with stub http server (WireMock)
In case producer changes its implementation and violates contract, the generated tests on producer side will fail developers have to either fix implementation or change the contract.
In case the contract get modified, tests on Consumer side may fail and developers needs to verify the contract and change implementation accordingly.
Consumer sample: contract-consumer
Provide consumer: contract-provider

Business blockchain use cases