Testing microservices the right way

Testing microservices the right way

Microservices shine in many aspects, but testability. Whenever you deploy a service, no matter how small it is, as long as it has dependencies, you have to keep them in mind. In Toptal, we realized the complexity of the integration testing when started our path from a monolithic application to microservices. In this talk, I’ll show what criteria we used to make a smart decision, what tools we haven’t chosen and how contract testing simplified our development flow and CI.

D61dc9b919be0bfb6d956bf7a6ee7292?s=128

Tatiana Shepeleva

September 28, 2019
Tweet

Transcript

  1. Testing microservices the right way Tatiana Shepeleva @ Toptal

  2. Tatiana Shepeleva @ Toptal

  3. • I am Quality Assurance Engineer • Love my job

    • 36 countries
  4. toptal.com

  5. Testing microservices the right way

  6. Microservices are great

  7. Microservices are light

  8. Microservices are isolated

  9. Microservices are fun

  10. Microservices are fun

  11. None
  12. ~2000 end-to-end* tests * also known as acceptance, UI or

    business tests
  13. ~3800 min

  14. None
  15. None
  16. None
  17. Complications • Have different databases • Use different languages •

    Work with different protocols
  18. +5 min/service

  19. What’s wrong with end-to-end tests? • Expensive and complex infrastructure

    • Time consuming • Flaky
  20. None
  21. None
  22. Test integration separately

  23. Requirements •Ruby •JavaScript •Scala/JVM •Elixir •WebSocket support •Easy to update

    tests •Provider can’t break consumers
  24. Record & Replay

  25. None
  26. None
  27. Record & Replay Polly.JS VCR Ruby ❌ ✅ JavaScript ✅

    ✅ Scala/JVM ❌ ✅ Elixir ❌ ✅ WebSocket support ✅ ❌ Easy to update tests ❌ ❌ Provider can’t break consumers ❌ ❌
  28. Fake server

  29. None
  30. Fake servers Wiremock Mockserver Ruby ✅ ✅ JavaScript ✅ ✅

    Scala/JVM ✅ ✅ Elixir ❌ WebSocket support ❌ ❌ Easy to update tests ✅ ✅ Provider can’t break consumers ❌ ❌
  31. Contract tests

  32. None
  33. None
  34. None
  35. Contract tests Spring Cloud Pact Ruby ❌ ✅ JavaScript ❌

    ✅ Scala/JVM ✅ ✅ Elixir ❌ Web Socket support Easy to update tests ✅ ✅ Provider can’t break consumers ✅ ✅
  36. Cons • Expensive and complex infrastructure ✅ • Time consuming

    ✅ • Flaky ✅
  37. Cons • Not a functional testing

  38. docs.pact.io

  39. Pact • Support different languages (Ruby, JS, Go, PHP, Python,

    JVM) • Framework-agnostic • Language-agnostic contract (JSON)
  40. None
  41. None
  42. None
  43. None
  44. None
  45. None
  46. None
  47. GraphQL?

  48. None
  49. None
  50. None
  51. None
  52. WebSockets?

  53. Experimental support Pact-JS

  54. gRPC?

  55. No but may be - #protobufs

  56. Storage for contracts • Your CI • Your codebase •

    Pact Broker
  57. Pact Broker • Stores versions and tags • Webhooks to

    trigger checks or notifications • can-i-deploy tool
  58. None
  59. None
  60. None
  61. None
  62. Pact Broker PactFlow

  63. None
  64. None
  65. How is it actually going to work?

  66. Consumer flow

  67. Consumer flow

  68. Consumer flow

  69. Consumer flow

  70. Consumer flow

  71. Consumer flow

  72. Consumer flow

  73. Consumer flow

  74. Consumer flow

  75. Provider flow

  76. Provider flow

  77. Provider flow

  78. Provider flow

  79. Provider flow

  80. Provider flow

  81. The Right Way • 10 instead of 3800 min •

    Contract tests are a part of unit tests • Number of end-to-end tests minimal
  82. The end Tatiana Shepeleva tati.engineer