contract testing with pact and quarkus

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.
  • 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. 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: