Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Microservices: test smarter not harder (LAST Conference 2018)

209 views

Published on

Microservices have become mainstream now.

We're able to respond to changing requirements and ship code to production more quickly than ever. Or, we were for our first microservice. And even our second and third.

But 5 years down the track, what happens when we end up with tens or hundreds of microservices that are now part of our core product - how do we know that we're safe to deploy to production without running hours of complex integration tests, defeating the purpose of using microservices in the first place?

Find out how contract tests can keep your microservices free from the burden of integration testing, and allow you to ship your code with speed and confidence.

Published in: Technology
  • D0WNL0AD FULL ▶ ▶ ▶ ▶ http://1lite.top/gFTsl6 ◀ ◀ ◀ ◀
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

Microservices: test smarter not harder (LAST Conference 2018)

  1. 1. 1 Microservices: Test smarter not harder Beth Skurrie (DiUS) @bethesque
  2. 2. A big problem soundify
  3. 3. Long time to market soundify
  4. 4. WHAT WE ARE KNOWN FOR 4 Microservices Solved problems New problems ● Integration tests ○ Slow tests ○ Easy to break ○ Hard to fix ○ Scale badly ○ Lots of set up ○ Flakey tests ignored ○ Takes dev time away from features ● Feature time to market A STORY
  5. 5. 5 To E2E test, or not to E2E test? A STORY
  6. 6. 6 What if there was another way?
  7. 7. 7 C P mock ANOTHER WAY
  8. 8. WHAT WE ARE KNOWN FOR 8 Test symmetry Solved problems New problems ● Hard to keep both sides in sync ● Fast feedback ● Few dependencies ● No dedicated environment ● Reliable ● Easy to debug ANOTHER WAY
  9. 9. 9 C P mock ANOTHER WAY
  10. 10. 10 C P mock ANOTHER WAY
  11. 11. PPCC mock contract ANOTHER WAY
  12. 12. WHAT WE ARE KNOWN FOR 12 Contracts Solved problems New problems ● ???● Keeping tests in sync ANOTHER WAY
  13. 13. Bug turnaround - minutes Contracts tests ANOTHER WAY
  14. 14. Know before you commit Contracts tests ANOTHER WAY
  15. 15. Make changes with speed and confidence Contracts tests ANOTHER WAY
  16. 16. Deploy independently Contracts tests ANOTHER WAY
  17. 17. Better API design (Consumer) Contracts tests ANOTHER WAY
  18. 18. Are not functional tests Contracts tests ANOTHER WAY
  19. 19. Are not load performance tests SLAs Contracts tests ANOTHER WAY
  20. 20. Are not good for “public” APIs (many, unknown consumers) (Consumer) Contracts tests ANOTHER WAY
  21. 21. Are not a silver bullet! Contracts tests ANOTHER WAY
  22. 22. 22 ANOTHER WAY
  23. 23. 23 Do I still need integration tests? ANOTHER WAY
  24. 24. 24 Integration test coverage Consequences of bug x Time to find bug x Time to release fix ANOTHER WAY
  25. 25. WHAT WE ARE KNOWN FOR 25 Speed up your releases Do less Do more ● Aggregated logging ● Metrics ● Semantic monitoring ● Alerting ● Correlation IDs ● Integration testing ANOTHER WAY
  26. 26. The journey continues
  27. 27. 27 ● Open source ● Multiple languages ○ JVM ○ .NET ○ Javascript ○ Python ○ Go ○ + more pact.io ● HTTP contracts ● Message contracts
  28. 28. 28 A B mock C P contract A CONTRACT TESTING JOURNEY
  29. 29. 29 A CONTRACT TESTING JOURNEY
  30. 30. 30 Pact Broker A CONTRACT TESTING JOURNEY
  31. 31. 31 Automate the contract exchange A CONTRACT TESTING JOURNEY
  32. 32. 32 WHEN the provider receives <some request> THEN it will return <some response> A CONTRACT TESTING JOURNEY
  33. 33. 33 WHEN the provider receives a GET request for /alligators/Mary THEN it will return a 200 OK response with a JSON body {“name”: “Mary”} A CONTRACT TESTING JOURNEY
  34. 34. 34 WHEN the provider receives a GET request for /alligators/Mary THEN it will return a 404 Not Found response a 200 OK response A CONTRACT TESTING JOURNEY
  35. 35. 35 GIVEN <the provider is in a certain state> WHEN the provider receives <some request> THEN it will return <some response> A CONTRACT TESTING JOURNEY
  36. 36. 36 You still need to think about test data A CONTRACT TESTING JOURNEY
  37. 37. A contract testing journey ● Automate the contract exchange ● You still need to think about test data A CONTRACT TESTING JOURNEY
  38. 38. 38 Contracts should focus on the messages, not the technology A CONTRACT TESTING JOURNEY
  39. 39. A contract testing journey ● Automate the contract exchange ● You still need to think about test data ● Contracts should focus on the messages, not the technology A CONTRACT TESTING JOURNEY
  40. 40. 40 Contracts should be as flexible as possible - but no more A CONTRACT TESTING JOURNEY
  41. 41. A contract testing journey ● Automate the contract exchange ● You still need to think about test data ● Contracts should focus on the messages, not the technology ● Contracts should be as flexible as possible - but no more A CONTRACT TESTING JOURNEY
  42. 42. 42 The other service needs to know when a contract has changed You need a way to introduce changes without breaking everything Contracts are not a substitute for good communication between teams A CONTRACT TESTING JOURNEY
  43. 43. 43 Pact Broker webhooks A CONTRACT TESTING JOURNEY
  44. 44. 44 Pact Broker tags A CONTRACT TESTING JOURNEY
  45. 45. 45 Contracts are STILL not a substitute for good communication between teams A CONTRACT TESTING JOURNEY
  46. 46. ● Automate the contract exchange ● You still need to think about test data ● Contracts should focus on the messages, not the technology ● Contracts should be as flexible as possible - but no more ● The provider needs to know when a contract has changed ● You need a way to introduce changes without breaking everything ● Remember: contracts are not a substitute for good communication between teams A contract testing journey A CONTRACT TESTING JOURNEY
  47. 47. 47 A CONTRACT TESTING JOURNEY
  48. 48. 48 You need to share the verification results as well as the contracts A CONTRACT TESTING JOURNEY
  49. 49. 49 Pact Broker verifications A CONTRACT TESTING JOURNEY
  50. 50. 50 A CONTRACT TESTING JOURNEY
  51. 51. 51 A CONTRACT TESTING JOURNEY
  52. 52. 52 If you can’t deploy your services independently, you don’t have microservices. You have a distributed monolith. A CONTRACT TESTING JOURNEY
  53. 53. 53 If you can’t deploy your services independently, you don’t have microservices. You have a distributed monolith. A CONTRACT TESTING JOURNEY Warning! Don’t build a distributed monolith
  54. 54. 54 Consumer version Provider version Verification result 11 31 success 12 31 failure 12 32 success 13 32 success 14 unknown “The Matrix” A CONTRACT TESTING JOURNEY
  55. 55. 55 A CONTRACT TESTING JOURNEY
  56. 56. 56 A CONTRACT TESTING JOURNEY
  57. 57. 57 A CONTRACT TESTING JOURNEY
  58. 58. 58 What about Swagger/Open API? OTHER TOOLS
  59. 59. 59 Provider contracts OTHER TOOLS
  60. 60. 60 Consumer contracts OTHER TOOLS
  61. 61. 61 A B mock/write C P pact swagger verify verify Pact+Swagger OTHER TOOLS
  62. 62. 62 Message Pact OTHER TOOLS C P contract
  63. 63. The talk ends, but the journey continues
  64. 64. WHAT WE ARE KNOWN FOR 64 Contracts Solved problems New problems ● ???● Deliver faster
  65. 65. 65 pact.io dius.tech/contrca4a slack.pact.io @pact_up Microservices: Test SMARTER not HARDER Beth Skurrie (DiUS) @bethesque
  66. 66. 66 Contract

×