End-To-End Tests can be longer in favor of writing duplicate test logic

In End-To-End Tests, no dependencies are mocked (exceptions). That means that when you want to test some features, you will have to go through the same steps that other End-To-End Tests already test. This is both slow (as E2E-Tests tend to be), as well as unnecessary.

The test that does the same steps as another test will fail if the first step is broken. In an even worse scenario, it might fail but it isn’t apparent that it fails because of the steps which the first test covers. It might look like there’s an issue in the logic which the requiring test is supposed to cover, while that issue wouldn’t arise if the first logic was working correctly.

In cases like these it is a better idea to only have one test, which will have a structure like: Given, When, Then, (Given), When, Then, (Given), When, Then,…. You set up the environment, execute the first system under test and make your assertions based on that. If necessary, you then set up the next system under test based on the state after the first test and continue.

The advantage with this way of testing is that it is clear that once one assertion fails, the later ones might be dependent on the first one working. No wrong test is debugged/fixed first. Execution is also faster.

Exceptions to this technique are too-common steps, which most E2E-Tests are dependent upon, like for example a login-functionality. Since these are extremely central features, they should be tested with smoke tests, which should always be fixed before other tests, shorten the feedback loop even further and therefore solve all issues mentioned here.