Totally agree. I am a fan of Test Pyramid model, where at the top you have a very small number of long running, complex tests (usually e2e), and at the very bot

Totally agree. I am a fan of Test Pyramid model, where at the top you have a very small number of long running, complex tests (usually e2e), and at the very bottom you have a lot of small, isolated and very fast unit tests. Testing everything in a browser/e2e provides a rather poor cost/benefit ratio, especially as the project grows and more features and tests are added, so it should be reserved for cases where it is really important. I like having e2e tests that cover the very core functionality and involve multiple parts of the stack. For example, if you have your rather typical app with a login modal, it's probably good to have a test that clicks on the button, makes sure that the modal is visible, and the user is redirected to the expected page after logging in. But testing if error message is displayed if email address is invalid? That's too much.