Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How to avoid common pitfalls with modern micros...

How to avoid common pitfalls with modern microservices testing

Have you ever wondered why your microservices break in production after all the tests have passed during CI/CD? Have you ever wondered if you’re testing too much or too little? If you want to learn about common pitfalls and how to catch them at build time rather than at runtime, this session is for you!

In this session we’ll share some common battle scars from our experiences in the field. Additionally, we will introduce the testing pyramid and explain why it is important in helping to continuously deploy microservices independently without fear. We will demonstrate, through a test-driven development approach, how the combination of Pact contract testing combined with Quarkus developer joy can help prevent your microservices from breaking in production.

Holly Cummins

October 13, 2022
Tweet

More Decks by Holly Cummins

Other Decks in Programming

Transcript

  1. @holly_cummins @edeandrea #Devoxx #RedHat Avoiding common pitfalls with modern microservices

    testing Holly Cummins Sr. Principal Software Engineer Red Hat @holly_cummins Eric Deandrea Sr. Principal Developer Advocate Red Hat @edeandrea
  2. @holly_cummins @edeandrea #Devoxx #RedHat Free copy (while they last)! Come

    see Eric at the Red Hat booth 
 (after the talk, not now) https://red.ht/quarkus-spring-devs
  3. @holly_cummins @edeandrea #Devoxx #RedHat Disclaimer We are not testers or

    even test experts But that’s ok - testing is every developer’s job!
  4. @holly_cummins @edeandrea #Devoxx #RedHat So what’s this talk about? Little

    Red Riding Hood visits the Death Star while trying not to burn your house down on the way to Egypt!
  5. @holly_cummins @edeandrea #Devoxx #RedHat “Our architecture is modern so it

    can never fail.” "We've analyzed their attack, sir, and there is a danger. Should I have your ship standing by?” “Evacuate? In our moment of triumph? I think you overestimate their chances."
  6. @holly_cummins @edeandrea #Devoxx #RedHat Netflix microservice architecture Testing with microservices

    is easy! Everything is decoupled! But….. if you only test the points, and not the lines … does the thing actually work?
  7. IBM Cloud © 2020 IBM Corporation The test pyramid end-to-end

    tests unit tests low effort high realism high value
  8. IBM Cloud © 2020 IBM Corporation The test pyramid end-to-end

    tests unit tests integration tests low effort high realism high value
  9. IBM Cloud © 2020 IBM Corporation The test pyramid (you

    can TDD at every level) end-to-end tests unit tests integration tests low effort high realism high value
  10. IBM Cloud © 2020 IBM Corporation tools evolve end-to-end tests

    unit tests integration tests low effort high realism
  11. IBM Cloud © 2020 IBM Corporation tools evolve end-to-end tests

    unit tests integration tests low effort high realism tests with application server test REST endpoints tests with a database
  12. @holly_cummins @edeandrea #Devoxx #RedHat our mock our code ✔ tests

    ✘ reality our code their actual code Why mocks aren’t enough
  13. IBM Cloud © 2020 IBM Corporation end-to-end tests unit tests

    integration tests low effort high realism high value
  14. IBM Cloud © 2020 IBM Corporation end-to-end tests unit tests

    integration tests low effort high realism high value contract tests
  15. @holly_cummins @edeandrea #Devoxx #RedHat ✔ our tests ✔ their tests

    ✔ reality our code their code contract test mock functional test Why mocks aren’t enough
  16. @holly_cummins @edeandrea #Devoxx #RedHat ✔ our tests ✘ their tests

    ✘ reality our code their code contract test mock functional test Why mocks aren’t enough
  17. @holly_cummins @edeandrea #Devoxx #RedHat ✘ our tests ✔ their tests

    ✘ reality Why mocks aren’t enough our code their code contract test mock functional test
  18. @holly_cummins @edeandrea #Devoxx #RedHat Some Contract Testing options • Pact

    • Spring Cloud Contract • OpenAPI schema validation + mock generation • Prism • Schemathesis
  19. @holly_cummins @edeandrea #Devoxx #RedHat Team maintaining the “other side” is

    not using Pact Consumer and provider do not have good communication P ! P
  20. @holly_cummins @edeandrea #Devoxx #RedHat Consumers can’t be identified (i.e. for

    public APIs) Consumer and provider do not have good communication Team maintaining the “other side” is not using Pact
  21. @holly_cummins @edeandrea #Devoxx #RedHat Can’t control data being used for

    provider responses Consumer and provider do not have good communication Team maintaining the “other side” is not using Pact Consumers can’t be identified (i.e. for public APIs)
  22. @holly_cummins @edeandrea #Devoxx #RedHat “Pass-through” APIs Consumer and provider do

    not have good communication Team maintaining the “other side” is not using Pact Consumers can’t be identified (i.e. for public APIs) Can’t control data being used for provider responses
  23. @holly_cummins @edeandrea #Devoxx #RedHat “Pass-through” APIs Consumer and provider do

    not have good communication Team maintaining the “other side” is not using Pact Consumers can’t be identified (i.e. for public APIs) Can’t control data being used for provider responses
  24. @holly_cummins @edeandrea #Devoxx #RedHat Functional, performance, or load testing Consumer

    and provider do not have good communication Team maintaining the “other side” is not using Pact Consumers can’t be identified (i.e. for public APIs) Can’t control data being used for provider responses “Pass-through” APIs
  25. @holly_cummins @edeandrea #Devoxx #RedHat Functional, performance, or load testing Consumer

    and provider do not have good communication Team maintaining the “other side” is not using Pact Consumers can’t be identified (i.e. for public APIs) Can’t control data being used for provider responses “Pass-through” APIs
  26. @holly_cummins @edeandrea #Devoxx #RedHat Pact vs Spring Cloud Contract? •

    Pact is polyglot! • Pact generates JSON acceptance contracts (Pacts) • Pact is consumer-driven whereas SCC is provider- driven • Pact allows consumers to specify provider test states • Pact broker
  27. @holly_cummins @edeandrea #Devoxx #RedHat …but I use Swagger/OpenAPI “My, what

    large teeth you have, Grandma” It looks the same, but the semantics are different.
  28. @holly_cummins @edeandrea #Devoxx #RedHat how annoying, the provider is returning

    204. the contract expects 404, so my test is broken. quarkus will return 204 by default. 204 vs 404 - it’s more about the theory behind REST...if a caller asks for a resource the server doesn't have, it should be a 404 - same way if a user types in an invalid URL into the browser ugh, it’s too late at night to care about REST theory. I’m just going to update the expectations in the test to match reality. what?! why is my other contract test broken now? 
 oh … because what I’m changing is a mock…. Based on a true story….
  29. @holly_cummins @edeandrea #Devoxx #RedHat Kubernetes Native Java with Quarkus Deployment

    Developer Joy • Quickly & easily build Kubernetes-Native Java applications • Industry leader in startup time and memory utilization for native and JVM applications • One step native executable generation • Leverage existing Java, Jakarta, MicroProfile, & Spring expertise • Imperative & reactive APIs side-by-side • Live coding with zero config https://www.infoq.com/articles/native-java-quarkus