Microservices testing consumer driven contracts using pact
•Als PPTX, PDF herunterladen•
0 gefällt mir•391 views
1) Consumer driven contracts (CDC) allow component tests to use stubs while also ensuring services work with real dependencies through contract testing. 2) CDC involves a consumer service testing against a contract while the provider validates the contract. This provides end-to-end test benefits without slow feedback cycles. 3) Pact tagging allows tracking compatibility between service versions to determine if a new version can be deployed, avoiding breaking changes between dependent services.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Ähnlich wie Microservices testing consumer driven contracts using pact
Ähnlich wie Microservices testing consumer driven contracts using pact (20)
Mehr von Prashant Kalkar
Mehr von Prashant Kalkar (9)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Microservices testing consumer driven contracts using pact
- 1. Microservices testing: Consumer driven contracts using Pact By Prashant Kalkar & Paresh Mahajan
- 3. Reducing the feedback loop How can we shorten the loop? ● Automation ● Scheduled builds - Continuous Integration ● Test segregation Larger the loop more costly it is.
- 5. Test pyramid
- 6. Testing challenges in Microservices ● Revisiting the testing terms ● Do we need any other types of test? ● Does the system works end-to-end?
- 7. Test pyramid in case of Microservices
- 8. Component Tests Tests a single service as black box. External services are stubbed.
- 9. Challenges in Component Tests
- 11. 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
- 12. End to End tests
- 13. 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
- 14. 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?
- 16. 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.
- 17. How CDC framework works: Contract / Pact stored between Consumer & Producer Contract/Pact Executed Against
- 18. Example in Discussion Consumer Provider
- 19. Consumer Test (Order Service)
- 20. Provider Test (User Service)
- 21. Demo ● Order service tests ● User service tests
- 22. 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
- 23. Avoid Pitfalls
- 24. 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
- 25. Releasability
- 26. What We Test Vs What We Release Monolith
- 27. What we Test Vs What We Release - Microservices
- 28. Compatibility CDC testing between latest services is not sufficient. How to answer ‘Can I deploy/release this service in Production?’
- 29. 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.
- 30. Pact Matrix
- 31. Producer and Releasability Latest Dev Prod TAGS 2. Execute all pacts against the Producer
- 33. 1. Run tests 2. New Pacts published 3. Triggered by Webhook
- 34. 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)
Hinweis der Redaktion
- Agile projects - CI, Auto, In the modern agile testing, essentially all the practices we follow are towards reducing the feedback loop.
- Test segregation - having different types of tests at different levels
- 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
- 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
- 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
- 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
- Benefits of component tests: Easy to set up No need of dedicated environment Readymade modern framework support e.g springboot, spring
- Benefits of component tests: Easy to set up No need of dedicated environment Readymade modern framework support e.g springboot, spring
- Setup cost
- Define the consumer, provider. Contractors created from consumers point of view. Owned by consumers. Provider has to fulfill those contracts.
- Clear the target folders mvn clean install Will generate the PACT files under target folder
- WSDL Postal’s Law: Be conservative in what you send, be liberal in what you accept