What are the most common BDD anti-patterns and how do you fix them?

1. UI-coupled scenarios — expose implementation, not behaviour:

# BAD — describes the UI, not the behaviour
When  the user clicks the button with id "submit-btn" and waits 2 seconds
Then  the div with class "success-toast" is visible

# GOOD — describes the business outcome
When  the user submits the registration form
Then  a confirmation message is displayed

Fix: write in business language. The UI is the implementation detail.

2. Scenario bloat — one scenario trying to test everything:

# BAD — 15 When steps, tests 5 different things
When  the user logs in
And   the user navigates to profile
And   the user updates their name
And   the user updates their email
...

Fix: one behaviour per scenario. Multiple Whens in a row are a smell.

3. No business involvement: Developers write all scenarios in isolation. Fix: Example Mapping sessions, regular review of feature files with POs.

4. Abusing Background:

Background:
  Given a database is configured  # too generic — always true
  And   the browser is open       # infrastructure, not business context

Fix: Background should contain meaningful business preconditions, not infrastructure setup.

5. Using BDD for technical tests:

# BAD — a unit test in Gherkin clothing
Scenario: UserService.createUser() returns DTO

Fix: Use JUnit/Jest for unit tests. BDD is for user-facing behaviour.

6. Combinatorial explosion via Scenario Outline: A single Outline with 50 rows of Examples creates 50 test cases that all test the same logic with trivially different data. Fix: boundary analysis — 3-5 representative cases, not exhaustive enumeration.