I have two e2e tests that run with browser automation that test the following user stories:
C: As a manager, I can add a member to my team.
D: As a manager, I can pay a member of my team.
The thing is, in order to do D I have to first do C. So writing one e2e test that goes ABC and once that goes ABCD is redundant!
My question is: what are some best practices for avoiding redundancy in e2e testing? One thing I have thought about is just writing ABCD, and including an assert after the C step. Though that means that if we have a failure at C, we have no information if D would have worked or not.
The answer is there in your question.
Think of it from user flow. You know that ABCD is one logical chunk and step D cannot be performed without performing step C.
So from e2e automation perspective, I would approach it in a way where I can mimic the end user action in one flow.
having expectation post step C makes sense and if there is a failure it is absolutely correct to not perform step D and test result should tell the same.
Also, Since e2e tests come at the top in the test pyramid, you can very well figure out the cost, Time, efforts of not having redundant tests.