The e2e mountain

I sometimes think of e2e test automation as exploring a mountain. I usually start with the Happy Path (or Value Path). You need to ensure everyone has a safe trip to the peak. Having one test to cover the whole path from e.g. "new user discovers our product" to "we generate value for the user" is obviously very valuable. Doing manual exploration without automatic coverage of this path in your CI/CD pipelines is potentially very wasteful.

From there we can deviate from the Happy Path to test acceptance criterias or bug regressions. We can explore different routes unguided and automate where it makes sense.

Due to the recommendations of "a test should only test one thing" you find yourself treading the Happy Path very often, stacking up test execution time. Refactoring these steps is a challenge. If for example you have a registration process with 7 steps and doing some checks on step 4, you might repeat the step 1 to 4 multiple times or write interactions like "fromOneToFour". The first approach is very un-DRY, the second approach leads to exponential interaction objects or complex decision logic in your test code, both a problem for maintainability.

Balance these two approaches by introducing base camps from where you explore the mountain. Do not use the Happy Path to get to the camp but introduce shortcuts! For browser based tests, utilize the API to set up the intended state.

When your gherkin script mentions a "given registered user", create a quick way to set up the registered user, that's the interaction that gets you to the closest base camp from where you can continue further step by step.

TL;DR: The Happy path should be traveled at least once e2e as close as possible to the user. Further tests must use shortcuts to quickly get to a specific state. More DRY, less execution time.