Devoxx UK 2019: "Testing Java Microservices: From Development to Production
Download as PPTX, PDF0 likes327 views
The document discusses the complexities of testing Java microservices, emphasizing the need for isolation of services and integration testing for production-like environments. It outlines various testing approaches, including test doubles and consumer-driven contracts, while also highlighting the importance of security testing. The conclusion reiterates key strategies for addressing these challenges in a microservices architecture.
Devoxx UK 2019: "Testing Java Microservices: From Development to Production
- 1. Testing Java Microservices: From Development to Production Abraham Marín-Pérez | Daniel Bryant
- 2. tl;dr ● Testing microservices brings additional challenges ● Pay special attention to integration surfaces ● Isolate services for loosely coupled tests ● Include tests that resemble production ● Make security testing a first-class citizen
- 3. Who am I? @danielbryantuk Product Architect at Datawire Consultant, Writer Java Champion, Conference Tourist @abrahammarin Developer, Consultant, Writer Associate of Equal Experts Software Plumber
- 4. Types of tests From Agile Testing, by Lisa Crispin and Janet Gregory
- 5. Challenges ● Cannot share a single environment: test locally ● Full ecosystem unsuitable for local testing ● Lack of control over third-party dependencies
- 6. Isolation
- 10. Isolating Parts: No Isolation Third Party
- 11. Isolating Parts: Unowned Components Third Party
- 12. Test Doubles
- 13. Test Doubles Dummy objects: passed around but never actually used. Fake objects: working implementations not suitable for production Stubs: provide canned answers to calls made during the test Spies: stubs that also record some information based on how they were called. Mocks: objects pre-programmed with expectations which form a specification of the calls they are expected to receive. Virtualisations: emulation of services, with expectations (not suitable for production) https://martinfowler.com/articles/mocksArentStubs.html
- 20. JUnit Example
- 21. API Simulation Thoughts ● Useful when a dependency is “expensive” to access or tricky to mock ● Facilitates error handling tests when dependency failure modes are challenging to recreate ● Simulations can be fragile and/or complicated
- 23. Isolating Parts: Service Interaction Third Party
- 25. API Contracts APIs are service contracts Many are producer-driven It’s possible to design outside-in: Consumer-Driven Contracts
- 30. Consumer-Driven Contract Frameworks https://docs.pact.io/ https://cloud.spring.io/spring-cloud-contract/
- 31. Consumer-Driven Contract Thoughts ● Great in low trust or low communication organisations ○ Act as a cue for a conversation ● Can be used to implement “TDD for the API” ● Resource intensive to create and maintain
- 33. Components
- 34. Isolating Parts: Single Service Third Party
- 35. Isolating Parts: Single Service
- 36. Isolating Parts: Single Service Test Doubles
- 37. Isolating Parts: Single Service
- 38. Isolating Parts: Single Service +
- 39. Isolating Parts: Single Service Fault Tolerance Test double configured to fail
- 41. Isolating Parts: Technicalities Third Party
- 42. Isolating Parts: Technicalities Test the Real Thing
- 44. Isolating Parts: Data Test Data ● Low Volume ● Low Diversity Production Data ● High Volume ● High Diversity
- 48. Isolating Parts: Data a а “a” “azǔ” U+0061 U+0430
- 51. Security: Code
- 55. Conclusion ● Testing microservices brings additional challenges ● Pay special attention to integration surfaces ● Isolate services for loosely coupled tests ● Include tests that resemble production ● Make security testing a first-class citizen
- 56. Thanks! Some code samples: https://github.com/orgs/continuous-delivery-in-java (with more coming soon!)
- 57. Bonus
- 59. Semantic Txns / Synthetic Monitoring https://martinfowler.com/bliki/SyntheticMonitoring.html
Editor's Notes
- #6: The quadrants hint at a number of challenges, which for microservices is even harder because… (and then bullet points) Full ecosystem: too large, too diverse, too evolving
- #8: to avoid gaps: expanding levels (concentric dotted lines, brittle, inefficient) chained levels (overlapping dotted lines, requires more management)
- #9: All about trade-offs to avoid gaps: expanding levels (concentric dotted lines, brittle, inefficient) chained levels (overlapping dotted lines, requires more management)
- #10: the whole is more than the sum of the parts, need to avoid silos
- #11: no isolation, but closest to user experience. Necessary evil?
- #12: biggest fully-controlled test. Need to use test doubles for unowned components Try to find better word for unowned
- #24: to avoid gaps: expanding levels (concentric dotted lines, brittle, inefficient) chained levels (overlapping dotted lines, requires more management)
- #35: Expect people to know this, just in case. Back-up: DBUnit, Utilis Prepare for anecdotes
- #36: Expect people to know this, just in case. Back-up: DBUnit, Utilis Prepare for anecdotes
- #37: Expect people to know this, just in case. Back-up: DBUnit, Utilis Prepare for anecdotes
- #38: Expect people to know this, just in case. Back-up: DBUnit, Utilis Prepare for anecdotes
- #39: QPid works with AMQP 1.0 ActiveMQ as well, but only later versions (5.8 or later)
- #42: Mention Franck Pachot’s talk about how SQL varies
- #56: “Copy” tl;dr Extra challenges when workin with microservice Test doubles, options Careful with Long-running queries, different tools for isolation,e tc. (one liner) security
- #57: Mention signing, no questions, need to leave!!