> To a programmer and maintainer of the software, E2E and acceptance tests have little value. They might not use the software at all. What they do care about is that the function, method, object, module, or package, does what says on the tin; that it returns the correct output when given a specific input; that it's performant, efficient, well documented, and so on. These users matter because they are the ones who will maintain the software in the long run.

I completely disagree with this take, as a professional programmer and maintainer of software. What I care about are two things: (1) if I make a change, I don't break existing user-visibile functionality, and (2) any feature I build actually addresses the use case I built it for.

E2E or integration tests are good for both of these purposes. Unit tests can help with purpose 1 as well, but not so much with purpose 2.

The disadvtange of relying solely on high level tests is that they don't pinpoint the error - if a test that integrates 5 components fails, I need to debug to even see which of these 5 components has a problem. In contrast, with a unit test, if a test fails, I typically know at least which specific file has a bug, if not the specific function. This is really nice, but not as critical - which is why unit tests are generally a nice to have, while integration/E2E tests are a necessity.