BDD and Cucumber interview questions

BDD is describing how a feature should behave in plain, structured language everyone agrees on — before it's built — so the same description drives the conversation, the code and the tests.

The point people miss: BDD is a collaboration practice first and a tool second. Cucumber and Gherkin are how you write it down, but the value is the shared understanding between product, dev and QA — not the .feature files themselves.

TDD is a developer discipline — write a failing unit test, make it pass, refactor. It's about the correctness of the code, in the developer's language. BDD is a step out: it describes behaviour from the user's point of view, in language the whole team shares, and usually drives higher-level tests.

They're not rivals — many teams do both: BDD scenarios frame what to build, TDD drives the units underneath. BDD answers "are we building the right thing?"; TDD answers "are we building the thing right?"

Gherkin is the plain-language syntax Cucumber reads. A scenario has three beats: Given sets up the starting state, When is the action being tested, Then is the expected outcome.

The discipline is one action per scenario. Given I'm logged in as an admin, When I delete a user, Then the user no longer appears. Keep Given to context, When to the single trigger, and Then to observable results — not internal state nobody can see.

A good scenario reads like a business rule: one behaviour, declarative, no UI mechanics. "When the customer applies an expired coupon, Then they see an error" — it survives a redesign because it says what, not how.

A bad scenario is a click script: "When I click #coupon-field, And I type SAVE10, And I click the button…". That's imperative, brittle, and tells a business reader nothing. If your Gherkin mentions CSS selectors or button IDs, it's stopped being BDD.

A Scenario is one concrete case. A Scenario Outline is a template run once per row of an Examples table — same steps, different data, using <placeholders>.

You reach for an outline when the same behaviour needs checking across several inputs: valid and invalid emails, boundary amounts, different roles. One outline with five Examples rows beats five copy-pasted scenarios — and it makes the data you're covering visible in one table.

Step definitions are the code behind each Gherkin line. Cucumber matches a step's text to a definition by a pattern (regex or Cucumber expression), captures any parameters, and runs that method.

So "When I apply the coupon SAVE10" maps to a function that takes "SAVE10" and does the actual work — clicking, calling the API, whatever. The Gherkin stays plain; the mechanics live here. One well-parameterised definition can serve many scenarios.

Background holds Given steps that every scenario in a feature file shares — it runs before each one, so you write the common setup once instead of repeating it.

Don't overload it. If the Background grows past a few lines, or scenarios only use half of it, it stops helping and hides context — a reader has to scroll up to understand any single scenario. Keep it to genuine, universal setup; anything specific belongs in the scenario.

Tags are labels like @smoke or @regression above scenarios. At run time you filter by them — run only @smoke on every push, the full @regression nightly. They also drive tagged hooks: a @db hook that seeds data only for scenarios that need it.

They're how one suite serves several purposes without duplicating scenarios. The discipline is a small, agreed vocabulary of tags — @wip, @smoke, @slow — not a sprawl nobody remembers.

Hooks are blocks that run around scenarios — Before, After, and their tagged variants. They hold the technical setup and teardown you don't want cluttering the Gherkin: open the browser, seed data, take a screenshot on failure, close connections.

The rule is that hooks are for plumbing, not behaviour. Anything a business reader should see — the state a scenario starts in — belongs in a Given or Background. If a hook is doing something the scenario's meaning depends on, it's hiding the test.

All three, together — that's the "three amigos": a business/product voice, a developer, and a tester, before the work starts. Product brings the intent, the developer flags what's technically hard, the tester surfaces the edge cases and the unhappy paths nobody mentioned.

When one person writes scenarios alone, you lose the whole benefit — QA writing them solo just produces tests in Gherkin, and product writing them alone misses the edge cases. The conversation is the deliverable; the .feature file is the memo.

Imperative scenarios spell out every mechanical step — click this, type that, press the button. Declarative scenarios state the intent — "When the customer checks out with an expired card" — and let the step definitions handle the how.

Declarative wins almost always: it reads as a business rule, survives UI redesigns, and stays short. Imperative Gherkin is brittle and unreadable to the non-technical people BDD exists to include. The skill is pushing detail down into steps and keeping the .feature file at the level of behaviour.

When you keep the tooling and drop the collaboration. Teams adopt Cucumber, skip the three-amigos conversation, and end up writing tests in Gherkin after the fact — now every test carries the overhead of a feature file, a step definition and pattern-matching, for none of the shared-understanding payoff.

It also fails when scenarios go imperative (brittle click-scripts), when the step library sprawls unmaintained, or when nobody outside QA ever reads the .feature files. If the business isn't in the loop, BDD is just a slower test framework — better to write plain automated tests.

A data table is a grid attached to a single step — the step definition receives it as structured data to loop over. "Given the following products:" then a table of names and prices, used once in that scenario.

An Examples table is different: it belongs to a Scenario Outline and runs the whole scenario once per row. Rule of thumb — a data table passes several values into one step; Examples runs one scenario many times. Mixing them up is a common beginner slip.

No. Cucumber is one tool that runs Gherkin; BDD is the practice of specifying behaviour collaboratively. You can do real BDD with SpecFlow, Behave, JBehave, or with no Gherkin tool at all — a whiteboard conversation and example-mapping before coding is BDD.

Equally, you can use Cucumber and do zero BDD, if you write feature files alone after the code exists. The tool is neither necessary nor sufficient. Interviewers ask this to separate people who've adopted a tool from people who understand the practice.