Microservices testing:
Consumer driven
contracts using Pact
By Paresh Mahajan & Prashant Kalkar
Essence of Testing
Reducing the feedback loop
How can we shorten the loop?
● Automation
● Scheduled builds - Continuous Integration
● Test segregation
Larger the loop more costly it is.
Build Pipeline
Test pyramid
Testing challenges in Microservices
● Revisiting the testing terms
● Do we need any other types of test?
● Does the system works end-to-end?
Test pyramid in case of Microservices
Component Tests
Tests a single service as black box. External services are stubbed.
Challenges in Component Tests
Integration tests
Issues with Integration tests
● Difficult to setup due to service dependency graph
● Can quickly increase in numbers for large number of services
● If setup incorrectly can be brittle to maintain
● Some stubs can be used but integration with real service still needs to be
covered in some other tests
● Stubs needs to be kept up to date to keep these tests relevant/useful
End to End tests
Issues with E2E tests
● Slow feedback
● Test data setup difficult
● Brittle, non-deterministic tests
● Harder to debug the test failure
● Parallel execution difficult to achieve
● No good way of scheduling them
Is there any golden mean which will allow us faster
execution as well as will give us more confidence if the
system works as a whole?
Consumer Driven Contracts
Consumer Driven Contracts (CDC)
● A CDC framework allow us to use the stub during component tests but also
provide a way to ensure that the service will work with actual services.
How CDC framework works:
Contract / Pact
stored between
Consumer & Producer
Contract/Pact
Executed Against
Example in Discussion
Consumer Provider
Consumer Test (Order Service)
Provider Test (User Service)
Demo
● Order service tests
● User service tests
CDC benefits
● Consumer component tests can be reused for CDC
● Solves the issues of stale stubs
● Provides end to end test benefits without extra cost
● Faster Feedback
● Can be part of Consumer and Producer (independent) pipelines
● Producer can be tested againsts all the Consumers
Avoid Pitfalls
Beware of Contract Coupling
● Contracts only contains fields required by Consumer. (It may not be same
as Producer’s entire response)
● When tested against producer extra fields in response are ignored
● Leads to loose coupling between consumers and producers
● Pact CDC framework implements Postel’s law while doing Pact verification
Releasability
What We Test Vs What We Release Monolith
What we Test Vs What We Release -
Microservices
Compatibility
CDC testing between latest services is not sufficient.
How to answer ‘Can I deploy/release this service in Production?’
Pact tagging
● Pact allows us to tag application versions.
● An application/service version can be tagged as say DEV or PROD.
● Pact broker maintains a compatibility matrix between applications.
Pact Matrix
Producer and Releasability
Latest
Dev
Prod
TAGS
2. Execute all pacts against the Producer
Consumer and
Releasability
1. Run tests
2. New Pacts published
3. Triggered by Webhook
Releasability and Pipeline Demo
● Consumer pipeline
● Provider pipeline
● Non compatible change in Provider
● Deploy Provider and Consumer till production
● Non compatible changes in consumer
● Provider fix as per new consumer contract
● Deploy new Provider to DEV
● Deploy new Consumer to DEV (can-i-deploy pass)
● Deploy new Consumer to PROD (can-i-deploy fail)
● Consumer changes (Pre-verified Contracts)
Thank you!
Git repositories:
https://github.com/prashant-ee/cdc-pact-expert-talk/
https://github.com/prashant-ee/user-service
https://github.com/prashant-ee/order-service

Microservices Testing: Consumer Driven Contracts using PACT

Editor's Notes

  • #3 Agile projects - CI, Auto, In the modern agile testing, essentially all the practices we follow are towards reducing the feedback loop.
  • #4  Test segregation - having different types of tests at different levels
  • #5 It is equally important to execute different types of tests at different levels and in the build pipeline Pipeline design lesser execution cost at earlier level
  • #6 Best of both We are further reducing the feedback loop More tests at unit level, faster and easy to maintain Less end 2 end tests - which are slow, brittle and requires high maintenance
  • #7 Revisiting the testing terms: Redefine in terms in case of micro-services world.. E.g. what is integration test in a MS world? Do we need any other types of test? Component test which will test one service as a black box Does the system works end-to-end? Which will give me more confidence
  • #8 Best of both We are further reducing the feedback loop More tests at unit level, faster and easy to maintain Less end 2 end tests - which are slow, brittle and requires high maintenance
  • #9 Benefits of component tests: Easy to set up No need of dedicated environment Readymade modern framework support e.g springboot, spring
  • #10 Benefits of component tests: Easy to set up No need of dedicated environment Readymade modern framework support e.g springboot, spring
  • #12 Setup cost
  • #17 Define the consumer, provider. Contractors created from consumers point of view. Owned by consumers. Provider has to fulfill those contracts.
  • #22 Clear the target folders mvn clean install Will generate the PACT files under target folder
  • #25 WSDL Postal’s Law: Be conservative in what you send, be liberal in what you accept