Pacts to the Rescue! Making your microservices play nicely together
summary
Pact enforces consumer-driven contracts by having the consumer tests run against a mock provider that writes JSON pact files, then replaying those requests against the real provider using provider states to set up test data; this catches interface drift early, keeps tests fast, and makes tests scale linearly rather than combinatorially. A central pact broker shares pacts, generates network graphs and docs, and lets teams decouple releases—REA shifted off slow brittle integration suites after finding one real bug but many false positives.
AI-written summary · about
chapters (34)
- 0:00Intro
- 0:38Integrated tests are a scam
- 1:05The problem with integrated tests
- 3:51Achieving test symmetry
- 5:24The problem with mocks
- 5:45No automated tools
- 8:20The downside of microservices
- 9:02The gateway to production
- 10:23System integration tests
- 11:04Packed
- 13:57Benefits of contracts
- 14:59Realworld examples
- 15:45Setting up the world
- 16:20Setting expectations
- 17:06Act and assert
- 18:11Service Provider
- 18:35Test Data
- 19:03Provider State
- 19:35Verification State
- 19:45Provider Verification
- 20:30Sharing Contract
- 21:15Pact Broker
- 22:55Autogenerated documentation
- 23:49Decouple releases
- 25:26Non HTTP services
- 26:23Underlying principles
- 27:23Do I still need integration tests
- 27:42Confidence vs responsiveness
- 28:08Ditching integration tests
- 29:24Consumerdriven contracts
- 30:12When should you not use Pact
- 31:28Language independence
- 32:32Summary
- 33:27Questions
related talks
59mUsing Pact to Deploy Microservice with Confidence
01h 21mMicro-Service Delivery Without the Pitfalls
24mHow to test microservices and stay sane
01h 13mContract Testing Made Easy: Master Pact for Microservices in C#
45mExecutable Agreements: Code, Collaborate, and Deploy with Confidence
22mCollaborating with Contracts
32mConsumer-Driven Contract: A better approach for API Testing
09m"Contract Testing 101"