The Role of E2E Tests in Microservices Architectures

From CitconWiki
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
  • Are E2E tests needed?
  • Another option is to run more elaborate integration tests not with all services but a small subset.
  • There's a very small user base, canary'ing isn't a great option.
  • Already utilizing PACT contract testing
  • Reframing E2E tests as smoke tests to minimize the number of them, since they are expensive to maintain, but they are definitely catching stuff at the moment.
  • A team can own many services, but a service only belongs to 1 team.
  • Should risky releases be done off hours?
  • Do you have a way to grade which are risky? e.g. infrastructure upgrades have been problematic
    • Infrastructure is actually a shared resource. All services are running a shared K8S cluster.
  • Each team has a QA champion... but not specifically a test automation specialist.
  • Tangent: Cucumber "actually not bad with this project"
  • "In a microservices architecture whee you are having E2E problems, there is a monolith hiding in there somewhere. You just have to find it."
Retrieved from "http://citconf.com/wiki/index.php?title=The_Role_of_E2E_Tests_in_Microservices_Architectures&oldid=16685"