Hi, I believe that we are really not on the same page.

In Agile testing is not about unit tests of one button or just e2e, it is about testing behaviors, not code. So, if a developer adds a new piece of code to implement one functionality, you expect the test to verify that the functionality works as expected. You test the behavior, not the code. And that is what becomes the documentation and what is very valuable when you are reviewing the code, because the intentions are present on the PR.

Additionally, waterfall QA classification for tests of unit or e2e has no correspondence in Agile. It is the developer who chooses what implementation details best suits in each case. In fact, you might find it surprising that the same guy who invented TDD, created extreme programming, who says that we have to tests behaviors, not code, is the one who invented the xUnit testing. Why? Because it is often useful enough to test if a functionality works as expected. So, the recommendation here is to use the most simple form of testing that serves your objective, because, using the most simple form for each case, ensures maximum speed and quick feedback.

Additionally, given that you should test all the behaviors, if there is some code not covered by any test, that means that that same code can be removed safely without breaking the test.

That is a complete shift in culture, I know. But I do recommend you to look at the videos that Robert C. Martin has on his clean coders page, so you will understand better what I'm saying.