The Role of E2E Tests in Microservices Architectures

From CitconWiki
Revision as of 18:14, 4 February 2023 by Robpark (talk | contribs) (Created page with "* 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'...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search
  • 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."