Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

[SC London] "Testing Microservices: from Development to Production

154 visualizaciones

Publicado el

Dividing a system into a series of services that communicate over an unreliable network naturally creates challenging conditions for testing inter-service interactions. Each service has its own functional requirements, and performance and fault-tolerance characteristics that need to be validated during development, the QA process, and continually in production. Join Daniel Bryant to learn about the theory, techniques, and practices that can help to overcome these challenges.

Overview and learning Outcomes:

• Introduction to the challenges of testing distributed microservice systems
• Learn tactics for isolating tests within a complex microservice ecosystem
• Join a whistle-stop tour of consumer-driven contract testing and API simulation
• Understand where to implement fault-injection within doubles in order to validate nonfunctional requirements in development and QA
• Understand the benefits of continually validating microservice systems running in production

Publicado en: Software
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

[SC London] "Testing Microservices: from Development to Production

  1. 1. Testing Microservices: From Development to Production Daniel Bryant @danielbryantuk
  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. Software Testing Funnel
  10. 10. Isolating Parts: No Isolation Third Party
  11. 11. Isolating Parts: Unowned Components Third Party
  12. 12. Test Doubles
  13. 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)
  14. 14. JUnit Example
  15. 15. 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
  16. 16. Use simulations appropriately... Sometime you need the real thing
  17. 17. Isolating Parts: Service Interaction Third Party
  18. 18. Focused on service/function Focused on system Contract Tests
  19. 19. API Contracts APIs are service contracts Many are producer-driven It’s possible to design outside-in: Consumer-Driven Contracts
  20. 20. Consumer-Driven Contracts
  21. 21. Consumer-Driven Contracts
  22. 22. Consumer-Driven Contracts
  23. 23. Consumer-Driven Contract Frameworks
  24. 24. 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
  25. 25.
  26. 26. Components
  27. 27. Isolating Parts: Single Service Third Party
  28. 28. Isolating Parts: Single Service
  29. 29. Isolating Parts: Single Service Test Doubles
  30. 30. Isolating Parts: Single Service
  31. 31. Isolating Parts: Single Service +
  32. 32. Isolating Parts: Single Service Fault Tolerance Test double configured to fail
  33. 33.
  34. 34. Isolating Parts: Technicalities Third Party
  35. 35. Isolating Parts: Technicalities Test the Real Thing
  36. 36. Isolating Parts: Technicalities
  37. 37. Isolating Parts: Data Test Data ● Low Volume ● Low Diversity Production Data ● High Volume ● High Diversity
  38. 38. Isolating Parts: Data
  39. 39. Isolating Parts: Data Marín Argüelles d’Hopital Garçon Castaña Strauß Fønss Bård かほる Александр สมชาย Φραγκόπουλος
  40. 40. Isolating Parts: Data
  41. 41. Isolating Parts: Data a а “a” “azǔ” U+0061 U+0430
  42. 42. ategory:OWASP_Top_Ten_Project
  43. 43. Security: Code
  44. 44. Security: Dependencies
  45. 45. Security: Container Images
  46. 46. Wrapping Things Up
  47. 47. 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
  48. 48. Thanks! Feel free to ask questions... @danielbryantuk
  49. 49. Bonus
  50. 50. Semantic Txns / Synthetic Monitoring
  51. 51.