Lesson 03 · BDD with Cucumber

Beyond the 1Z0-830 exam

BDD (Behaviour-Driven Development) expresses tests as plain-language scenarios that non-developers can read and even write. Cucumber is the dominant Java tool. The skill here is judgement: BDD is powerful collaboration glue and an expensive habit if misapplied.

Objectives

After this lesson you will be able to:

• Read and write Gherkin scenarios (Given/When/Then).
• Glue steps to Java with step definitions.
• Decide when BDD's overhead is worth it.

Gherkin — the feature file

A .feature file describes behaviour in structured natural language:

Feature: Discount eligibility

  Scenario: Members over 18 get a discount
    Given a logged-in member aged 25
    When they view the checkout
    Then a 10% discount is applied

  Scenario Outline: Age threshold
    Given a logged-in member aged <age>
    Then discount eligibility is <eligible>
    Examples:
      | age | eligible |
      | 17  | false    |
      | 18  | true     |

• Given = context/precondition, When = action, Then = expected outcome.
• A Scenario Outline + Examples table is Gherkin's data-driven form (like a parameterized test).

Step definitions — gluing Gherkin to Java

Each Gherkin line is matched to a Java method by annotation + a regex/Cucumber-expression:

public class CheckoutSteps {
    private Member member;
    private Checkout checkout;

    @Given("a logged-in member aged {int}")
    public void aMemberAged(int age) {
        member = aMember().withAge(age).build();   // reuse the builder from L02!
    }

    @When("they view the checkout")
    public void viewCheckout() {
        checkout = new Checkout(member);
    }

    @Then("a {int}% discount is applied")
    public void discountApplied(int pct) {
        assertThat(checkout.discountPercent()).isEqualTo(pct);
    }
}

{int} is a Cucumber-expression placeholder bound to the method parameter. The plain-language step and the code stay in sync because an unmatched step is a failure, not a silent skip.

When BDD pays off — and when it doesn't

Worth it when:

• Non-technical stakeholders (product, QA, BAs) need to read or co-author acceptance criteria.
• The scenarios are stable, business-facing behaviour worth documenting in a shared language.
• "Living documentation" that's executed (so it can't go stale) has real value to the team.

Not worth it when:

• It's just developers writing tests for developers — the Gherkin layer is then pure overhead; a plain JUnit + AssertJ test is shorter and clearer.
• You'd use it for fine-grained unit tests — Gherkin is far too verbose for that.
• Nobody outside engineering ever reads the .feature files.

Trap — BDD theatre

The most common failure is writing Gherkin nobody non-technical reads, so you've paid the cost (feature files + step-definition glue + regex maintenance) for none of the collaboration benefit. BDD is a communication tool first; if the conversation isn't happening, you just want JUnit.

SDET note

Cucumber runs on the JUnit platform, so it lives in the same suite, tags, and CI as your other tests. Keep step definitions thin — they should call into the same builders/object mothers and domain helpers your unit tests use, not contain logic of their own.

Key Takeaways

• Gherkin describes behaviour as Given/When/Then; a Scenario Outline + Examples is its data-driven form.
• Step definitions (@Given/@When/@Then) glue each plain-language line to a Java method via Cucumber expressions; unmatched steps fail.
• BDD pays off for stakeholder collaboration and executable living documentation — not for developer-only or fine-grained unit tests.
• Beware BDD theatre: Gherkin nobody non-technical reads is pure overhead.
• Keep step definitions thin, reusing the same fixtures/domain helpers as your unit tests.

Lesson Quiz

Lesson Quiz · BDD with Cucumber0 / 4

1. In Gherkin, what does a 'When' step represent?

   • AThe expected outcome
   • BThe action/event under test
   • CThe precondition
   • DA comment

2. How is a Gherkin step connected to executable code?

   • ABy line number
   • BBy a step-definition method annotated @Given/@When/@Then matching the step text
   • CBy a SQL trigger
   • DIt runs automatically with no code

3. When is BDD/Cucumber most worth its overhead?

   • AFor every unit test
   • BWhen non-technical stakeholders read or co-author the scenarios (collaboration + living docs)
   • CTo make tests run faster
   • DTo avoid writing assertions

4. What's 'BDD theatre'?

   • ARunning BDD tests in parallel
   • BWriting Gherkin that nobody non-technical reads — paying the cost without the collaboration benefit
   • CUsing AssertJ inside steps
   • DA Cucumber reporting plugin

---

Next: Parallelism, Flakiness & Reporting.