Automation Tools
BDD & Cucumber Interview Questions & Answers
BDD and Cucumber interview questions on Gherkin syntax, step definitions, hooks, tags, scenario outlines, data tables, runners and common BDD anti-patterns.
Interview Questions
Showing 15 of 40 questions
BDD is a collaborative practice where business, developers and testers agree on system behaviour through concrete examples before building it. Those examples are written in a shared language like Gherkin and can be automated as living documentation.
It's a short meeting where a business person (usually the PO), a developer and a tester discuss a story and agree on concrete examples and acceptance criteria before development. It surfaces misunderstandings and edge cases early.
TDD is a developer practice of writing a failing unit test before the code, focused on design and correctness of units. BDD works at the behaviour level, uses business-readable examples, and involves the whole team.
Cucumber is a tool that reads Gherkin feature files and runs each step by matching it to a step definition method written in code. It supports Java, JavaScript/TypeScript, Ruby and others; SpecFlow/Reqnroll and behave are similar tools for .NET and Python.
Feature, Rule, Scenario (or Example), Given, When, Then, And, But, Background, Scenario Outline (or Scenario Template) with Examples, plus doc strings, data tables, tags and comments.
Given describes the starting state, When describes the single key action or event, and Then describes the observable outcome. A good scenario usually has one When, and Then checks outcomes the user or system can observe, not internals.
Imperative scenarios list UI steps like clicking buttons and typing fields, while declarative scenarios describe intent, like 'When I log in as a premium user'. Declarative style is preferred because it reads like business rules and survives UI changes.
A step definition is a method annotated with Given/When/Then and a Cucumber Expression or regex that matches the step text. Parameters like {int} or {string} are captured and passed as method arguments.
Cucumber Expressions are a simpler alternative to regular expressions with built-in parameter types like {int}, {float}, {word} and {string}, optional text in parentheses and alternatives with a slash. Regex is still supported when you need more control.
In Cucumber-JVM, annotate a method with @ParameterType giving a regex; the method name becomes the parameter name and it converts the matched text into an object. Steps then use {name} in their expressions.
An ambiguous error happens when one step text matches more than one step definition, and a duplicate error when the same expression is defined twice. Cucumber needs exactly one match per step, so I make expressions more specific or reuse the existing step.
A Scenario Outline is a template run once per row of its Examples table, with <placeholders> replaced by column values. I use it when the same behaviour must be checked with several input-output combinations.
A data table passes structured data to a single step, unlike a Scenario Outline which runs the scenario many times. In the step definition I receive a DataTable and convert it to lists, maps or typed objects.
A Scenario Outline repeats the whole scenario for each Examples row, so each row is an independent test. A data table supplies multiple rows of data to one step within a single scenario run.
Doc strings pass a multi-line block of text to a step, enclosed in triple quotes or triple backticks, optionally with a content type. They are handy for JSON payloads or email bodies.