Microservices testing with Pact
•Descargar como PPTX, PDF•
0 recomendaciones•391 vistas
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.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (19)
Similar a Microservices testing with Pact
Similar a Microservices testing with Pact (20)
Más de Prashant Kalkar
Más de Prashant Kalkar (9)
Último
Último (20)
Microservices testing with 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)
Notas del editor
- 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