contract testing with pact and quarkus
src: Contract testing with Pact and Quarkus by Holly Cummins - 2023-05-16
Abstract
- How do I know the whole system works? without losing the goodness of microservices?
 - Testing in isolation is not enough.
 - microservice architecture is definitely distributed, but that does not mean decoupled.
 - As soon there’s communication, there’s misunderstanding.
 - Mocks aren’t enough: reality is often quite different with what we mocked.
 - We need to have contract tests so that if the provider or consumer changes, the tests will fail.
 
- contract testing is located in the middle of the test pyramid.
 - Do not test the mock.
 - Provider-driven contract testing.
 
- Pros:
 
- Familiar contract format.
 - Consumer cannot break provider CI.
 - Provider does not communicate with consumers (like a broadcast).
 - Cons:
 
- Provider does not get insight into how API is being used.
 - Consumer-driven contract testing.
 ![]()
- Pros:
 
- Rich semantic testing
 - Provider can “develop to the test’ instead of developing speculatively.
 - Cons:
 
- Existing spec assets cannot be re-purposed.
 - Provider needs to identify consumers.
 - contract testing options: