BDD is a subclass of TDD, and is more similar to ATDD (Acceptance Test Driven Development), where…
Eric Elliott

Good stuff.

And, I definitely agree, it’s usually a pipe dream to think stakeholders are going to read your BDD/acceptance tests, so that’s not a good reason for doing something like wasting a lot of time on a DSL.

One rule my team still follows, however, is if it’s not something the end user would be able to observe, don’t use it in your assertions in e2e testing. If you’re dispatching a Redux action under the hood, for example, don’t assert it was dispatched in your e2e test. Instead, assert that you observe something different on the page.

Otherwise, you’re pretty much guaranteed that your suite will be heavily overlapping your unit tests and will also be unnecessary coupled to implementation.

We also only test the happy path with e2e tests, then the edge cases are covered only by unit tests. Check out Martin Fowler’s testing pyramid concept. For the complete opposite argument, which you and I seem to disagree with here, check out this video and pay attention to what DHH is saying (basically, just do lots of integration tests, although I don’t get how he doesn’t have the 24-hour integration test suite problem).