</>

Technology

Cucumber

Difficulty

Advanced

Interview Question

What are Cucumber anti-patterns and BDD best practices?

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

PracticeRule
Scenario focusOne business rule per scenario
Step reuseShared steps in CommonSteps.java
TagsAlways tag: @smoke, @regression, @P1, module tags
BackgroundOnly shared Given steps (not When/Then)
NamingScenarios describe "what", not "how"
DataScenario Outline for data-driven, not hardcoded
DIAlways use PicoContainer, never static state
HooksBrowser setup in @Before, not in feature files
Step countMax 5–7 steps per scenario
File sizeMax 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?

Follow AutomateQA

Related Topics