Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Devoxx UK 2019: "Testing Java Microservices: From Development to Production

119 Aufrufe

Veröffentlicht am

Testing microservices is challenging. Dividing a system into components (à la microservices) naturally creates inter-component dependencies, and each service has its own performance and fault-tolerance characteristics that need to be validated during development, the QA process, and continually in production. Attend this session to learn about the theory, techniques, and practices needed to overcome this challenge.

Join us, and:

Get an introduction to the challenges of testing distributed microservice systems
Learn how to isolate tests within a complex microservice ecosystem
Hear about several tools for automating vulnerability and security scanning for code, dependencies, and deployment artifacts

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Devoxx UK 2019: "Testing Java Microservices: From Development to Production

  1. 1. Testing Java Microservices: From Development to Production Abraham Marín-Pérez | Daniel Bryant
  2. 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. 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. 4. Types of tests From Agile Testing, by Lisa Crispin and Janet Gregory
  5. 5. Challenges ● Cannot share a single environment: test locally ● Full ecosystem unsuitable for local testing ● Lack of control over third-party dependencies
  6. 6. Isolation
  7. 7. Isolating Parts Third Party
  8. 8. Isolating Parts Third Party
  9. 9. Isolating Parts: No Isolation Third Party
  10. 10. Isolating Parts: Unowned Components Third Party
  11. 11. Test Doubles
  12. 12. 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
  13. 13. JUnit Example
  14. 14. 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
  15. 15. Isolating Parts: Service Interaction Third Party
  16. 16. Focused on service/function Focused on system Contract Tests
  17. 17. API Contracts APIs are service contracts Many are producer-driven It’s possible to design outside-in: Consumer-Driven Contracts
  18. 18. Consumer-Driven Contracts
  19. 19. Consumer-Driven Contracts https://www.baeldung.com/pact-junit-consumer-driven-contracts
  20. 20. Consumer-Driven Contracts
  21. 21. Consumer-Driven Contract Frameworks https://docs.pact.io/ https://cloud.spring.io/spring-cloud-contract/
  22. 22. 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
  23. 23. https://bit.ly/2p68gBS
  24. 24. Components
  25. 25. Isolating Parts: Single Service Third Party
  26. 26. Isolating Parts: Single Service
  27. 27. Isolating Parts: Single Service Test Doubles
  28. 28. Isolating Parts: Single Service
  29. 29. Isolating Parts: Single Service +
  30. 30. Isolating Parts: Single Service Fault Tolerance Test double configured to fail
  31. 31. https://technology.cap-hpi.com/blog/unit-testing-what-benefits-you-can-reap/
  32. 32. Isolating Parts: Technicalities Third Party
  33. 33. Isolating Parts: Technicalities Test the Real Thing
  34. 34. Isolating Parts: Technicalities
  35. 35. Isolating Parts: Data Test Data ● Low Volume ● Low Diversity Production Data ● High Volume ● High Diversity
  36. 36. Isolating Parts: Data
  37. 37. Isolating Parts: Data Marín Argüelles d’Hopital Garçon Castaña Strauß Fønss Bård かほる Александр สมชาย Φραγκόπουλος
  38. 38. Isolating Parts: Data
  39. 39. Isolating Parts: Data a а “a” “azǔ” U+0061 U+0430
  40. 40. www.owasp.org https://www.owasp.org/index.php/C ategory:OWASP_Top_Ten_Project
  41. 41. Security: Code
  42. 42. Security: Dependencies
  43. 43. Security: Container Images github.com/arminc/clair-scanner
  44. 44. Wrapping Things Up
  45. 45. 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
  46. 46. Thanks! Some code samples: https://github.com/orgs/continuous-delivery-in-java (with more coming soon!)
  47. 47. Bonus
  48. 48. https://medium.com/@copyconstruct/testing-microservices-the-sane-way-9bb31d158c16 Evolution of QA
  49. 49. Semantic Txns / Synthetic Monitoring https://martinfowler.com/bliki/SyntheticMonitoring.html

×