There aren't too many test frameworks that support that test strategy.. Cypress.io is one. So it enables so many parts of the test architecture. - serves as an API client, with API e2e tests for your backend services (cy.request, and Gleb's cy.api) - enables ui-integration testing by isolating the tests to an integration of your UI components, stubbing the network - enables isolated testing of your components with Component Testing (this will change everything!) - probably the best if not one of the best for ui-e2e testing Here's some reading with examples applied to mid size application. https://github.com/muratkeremozcan/react-hooks-in-action-with-cypress#what-to-test-where-component-vs-ui-integration-vs-ui-e2e . TL, DR; test everything you can at the lowest level component using Component Testing; when that is limiting move to the parent component, when that is limiting move further up; ui-integration (ui-component-integration, stubs the network) and ui-e2e where backend is needed. Most of the time the backend is not needed. What parts of the test architecture remain, that maybe Cypress doesn't focus on directly? - backend load/perf (k6 is a great tool), ui-perf with Lighthouse (there is a Cypress plugin) - consumer driven contract testing with Pact.io (they have a few Cypress integrations) which enable some cross service integration testing prior to a common deployment - not too many practical types of testing remain after that, but you can get inspired from https://dev.to/muratkeremozcan/mostly-incomplete-list-of-test-methodologies-52no My golden rules in testing: - It’s always cost v confidence - cost = creation + execution + maintenance - What you can avoid testing is more important than what you are testing