For self contained algorithmic or calculation code with simple inputs and outputs, TDD with unit tests really shines. If your app is mostly lower level code that does a lot of complex "thinking" especially with simple inputs and outputs then you probably should have mostly unit tests.
Integration/E2E testing algorithmic/calculation on that kind of code leads to tests that could take 100x longer to run - unnecessarily.
However, it's very common to have very little code of this type. If an app is very integration code heavy (it sends/receives messages, does CRUD, calls APIs, sends emails, etc.) then the opposite is true - you only want to have integration / end to end tests.
Unit testing that kind of code leads inevitably to mimetic tests.
End to end tests can make it hard to get a good granular view of an issue. I agree with this. However, this can be solved by integrating high quality debugging tools to the end to end tests - automatically grabbing screenshots, logs, external API calls, etc.
For self contained algorithmic or calculation code with simple inputs and outputs, TDD with unit tests really shines. If your app is mostly lower level code that does a lot of complex "thinking" especially with simple inputs and outputs then you probably should have mostly unit tests.
Integration/E2E testing algorithmic/calculation on that kind of code leads to tests that could take 100x longer to run - unnecessarily.
However, it's very common to have very little code of this type. If an app is very integration code heavy (it sends/receives messages, does CRUD, calls APIs, sends emails, etc.) then the opposite is true - you only want to have integration / end to end tests.
Unit testing that kind of code leads inevitably to mimetic tests.
End to end tests can make it hard to get a good granular view of an issue. I agree with this. However, this can be solved by integrating high quality debugging tools to the end to end tests - automatically grabbing screenshots, logs, external API calls, etc.