Cucumber BDD Visualizer

Gherkin: Given, When, Then

Gherkin is the plain-language format Cucumber reads. A scenario is written as Given (context), When (action) and Then (outcome), with And/But for extra steps. The value is that a product owner can read the scenario without knowing any code, while it still drives real automation underneath.

Step definitions: gluing Gherkin to code

Each Gherkin step is matched to a step definition — a Java method annotated with @Given, @When or @Then and a regular expression or Cucumber expression. Parameters in the step text are captured and passed to the method, so When I search for "selenium" maps to a method that receives "selenium".

Scenario Outline and Examples

To run the same scenario with different data, use a Scenario Outline with an Examples table. Each row becomes a separate test run — this is data-driven testing in BDD form, and a very common interview talking point.

Hooks and tags

@Before and @After hooks run setup and teardown around each scenario (open/close the browser, reset data). Tags like @smoke or @regression let you select which scenarios to run, so one suite can serve many purposes from CI.

How to use this tool

1. Read the sample Gherkin scenario in the tool.
2. See each step highlight as it maps to its Java step definition.
3. Switch to a Scenario Outline and watch each Examples row run as a separate test.
4. Toggle a tag to see how Cucumber filters which scenarios run.

Worked example

A Gherkin scenario and the step definition it maps to:

# search.feature
Scenario: Search returns results
  Given I am on the home page
  When I search for "selenium"
  Then I should see results for "selenium"

// StepDefs.java
@When("I search for {string}")
public void iSearchFor(String term) {
    searchPage.search(term);
}

Common mistakes to avoid

• Writing imperative, UI-detail steps (click, type) instead of business-readable behaviour.
• Duplicating step definitions that could share one parameterised step.
• Putting assertions in Given/When steps instead of Then.
• Overusing BDD for tests no non-technical stakeholder will ever read — it adds overhead with no benefit.

Frequently asked questions

Related guides & tools