Fewer e2e tests means faster feedback on what actually broke
Languages & FrameworksI used to write end to end tests for everything. Click this button, fill that form, check the result. It felt safe but every test run took forever and when something broke, all I got was a screenshot showing me a blank form or a missing element. Then I'd have to dig through logs to find which function actually failed.
The shift was simple: keep the e2e tests only for the flows that would genuinely tank the business if they stopped working. For me that's user signup, payment processing, and core search. Everything else moved down to integration tests with Vitest where I test the actual functions and API endpoints directly.
Now my test suite runs in under a minute instead of ten. When a test fails, Vitest tells me exactly which function broke and why, not just that something on the page is wrong. I can verify a complex checkout flow with an integration test that sets up the database, calls the controller, and checks the response in about thirty lines.
The honest caveat is that this approach assumes you have good logging and error handling already in place. If your app swallows errors or logs them poorly, you'll miss bugs that e2e tests would have caught. I also still need the handful of e2e tests because screenshots do catch visual regressions and weird browser quirks that integration tests miss entirely.