>you can't figure out which part of your stack is causing them
If your debugging tools are halfway decent you certainly can.
If your debugging tools are halfway decent you certainly can.
You're either dreaming, or haven't worked on anything complex enough to see it yet. E2E means system test, whether or not you think it is, including back end. In almost any real software in 2020 that means multiple debuggers, monitors, logs, god knows what.
But if you're testing a monolith, sure. Your system is one unit, so unit test your monolith and enjoy your debugger.
If you're testing a monolith outside of something like embedded or basic app testing, quit, because the company you're working for built a monolith.
Inactionable doesn't mean "not possible", it means "more trouble than it's worth." That's why it's advisable to do E2E on P0 cases and not really advisable to do it for P3 cases. You can do tooling work to move the bar for how much trouble you have to put in, but "try harder" misses the point.
If you can't write the former without acceptable debugging tools your tests suck and you should rewrite them.
If you are a team writing a micro service in an ecosystem of micro services, you need to write E2E tests that mock systems external to yours and have very clear agreements/contracts about how they interact as well as a QA team to test the system as a whole coz otherwise each bug that crosses a layer degenerates into an orgy of finger pointing. Ideally debugging at that scale should be rare and done with multiple members from multiple teams.
I’ve never considered the single service tests E2E, more either a component test suite or a public API unit test suite (same thing).
I agree you’d want those with collaborators mocked, and it’s where I’d lean the bulk of my test strategy for a system like that from a QA POV (as well as promoting internal API unit testing from a dev POV).