Answer
Cucumber Anti-Patterns and Best Practices
Anti-Pattern 1: UI Implementation in Gherkin
Gherkin
-- BAD: Implementation details in feature file
When the user clicks the button with id "login-btn"
And waits 3 seconds for the page to load
Then the div with class "dashboard-content" should be visible
-- GOOD: Business behavior
When the user logs in with valid credentials
Then the dashboard should be accessible
Anti-Pattern 2: One Monolithic Step Definition File
Java
// BAD: Everything in one file (500+ lines)
public class AllSteps {
@Given("...") // login step
@When("...") // checkout step
@Then("...") // admin step
@Given("...") // 50 more steps...
}
// GOOD: Split by feature domain
LoginSteps.java
CheckoutSteps.java
AdminSteps.java
CommonSteps.java
Anti-Pattern 3: Static WebDriver
Java
// BAD: Not thread-safe, breaks parallel execution
public class StepDefs {
public static WebDriver driver;
}
// GOOD: PicoContainer DI
public class StepDefs {
private final ScenarioContext ctx;
public StepDefs(ScenarioContext ctx) { this.ctx = ctx; }
}
Anti-Pattern 4: Overloaded Scenarios
Gherkin
-- BAD: One scenario tests too many things
Scenario: Full application test
Given user logs in
When user adds product to cart
And user applies coupon
And user changes shipping address
And user selects payment method
And user places order
And user checks order history
And user logs out
Then ... 30 more steps
-- GOOD: Focused scenarios
Scenario: User completes checkout
Given the user has an item in their cart
When the user completes checkout with standard shipping
Then the order confirmation number should be generated
Anti-Pattern 5: Skipping 3 Amigos
CODE
BAD workflow:
QA writes all feature files alone
ā Dev implements without review
ā Feature files don't match real behavior
ā All tests fail
GOOD workflow:
BA + Dev + QA session (3 Amigos)
ā Write Gherkin together
ā Dev confirms feasibility
ā QA confirms testability
ā BA confirms business accuracy
Anti-Pattern 6: Fragile Locator-Dependent Steps
Gherkin
-- BAD: Couples scenario to locators
When the user clicks the 3rd li in the ul with id "nav-menu"
-- GOOD: Business-intent driven
When the user opens the settings menu
Best Practices Summary
| Practice | Rule |
|---|---|
| Scenario focus | One business rule per scenario |
| Step reuse | Shared steps in CommonSteps.java |
| Tags | Always tag: @smoke, @regression, @P1, module tags |
| Background | Only shared Given steps (not When/Then) |
| Naming | Scenarios describe "what", not "how" |
| Data | Scenario Outline for data-driven, not hardcoded |
| DI | Always use PicoContainer, never static state |
| Hooks | Browser setup in @Before, not in feature files |
| Step count | Max 5ā7 steps per scenario |
| File size | Max 10 scenarios per feature file |
Scenario Writing Checklist
CODE
ā Can a non-technical BA read and understand this?
ā Does it describe behavior, not implementation?
ā Does it have a clear pass/fail outcome in Then?
ā Could it run independently of all other scenarios?
ā Does it have the right tags?
ā Is it under 7 steps?
