[pydry]

E2E have higher capex and lower opex - hard to set up well, cheap to maintain if you do.

Low level tests are the reverse - easy to get started, hard to maintain.

If youve got a really well oiled framework e2e tests are spectacular but getting to that point can vary between easy and "harder than the actual project itself" and if you half ass it (which most people do) it ends up a useless flaky mess.

[hinkley]

> cheap to maintain if you do.

I've only seen this with projects in maintenance mode. Any major functionality changes tend to land teeth-first in the E2E tests, and after a few cycles of that you start dragging your feet a bit on major changes. E2E tests tend to lock in assumptions about the structure of your application, not just the minutia (which is not without its own set of problems).

It is more difficult to get people to write maintainable E2E tests than it is getting them to write maintainable application code, so I've retreated and retrenched.

[pydry]

Weird Ive always found the opposite - E2E tests tend to make the fewest assumptions about the way the application is built.

In most cases we could literally rewrite the whole app in a different language and barely change the tests.

E2E tests do require a solid infrastructure though. If you have tooling problems you cant fix (e.g. you hit selenium's dark corners way too frequently because your web app is even a bit quirky) then maintainence cost can quite quickly exceed any benefit you derive.

Ive also hit this problem of "Id have to create my own equivalent of selenium for interacting with this app's interface" a few times and yeah, the required engineering effort to do it well explodes to the point where its just not worth it.