Interview Corner — Cucumber BDD

A: They serve different purposes. Cucumber is a BDD framework — you write tests in plain English (Gherkin) and map them to Java step definitions. TestNG is a test execution framework — annotations, assertions, DataProviders, parallel execution, and XML suites. In practice, they work together: Cucumber handles the BDD layer (feature files + step definitions), TestNG provides the runner and execution engine. The runner class extends AbstractTestNGCucumberTests.

A: Four ways: (1) Inline parameters with Cucumber Expressions — {string}, {int}, {double} in step definitions. (2) Scenario Outline with Examples table — same scenario, different data rows. (3) Data Tables — structured key-value pairs or lists of records passed directly to a step. (4) DocStrings — multi-line text blocks. I use Scenario Outline for login/search data-driven tests, Data Tables for form filling, and inline parameters for simple values.

A: Scenario runs once with fixed data. Scenario Outline is a template that runs once per row in the Examples table — each row provides different values for the placeholders. Scenario Outline is the BDD equivalent of TestNG DataProvider. Use Scenario for specific test cases and Scenario Outline when you need to test the same flow with multiple data sets.

A: @Before runs before each scenario — I use it to initialize WebDriver and open the browser. @After runs after each scenario — I capture screenshots on failure with scenario.attach() and close the browser. @BeforeStep and @AfterStep run before and after each step — useful for detailed logging. Hooks can be conditional with tags: @Before("@banking") only runs for banking-tagged scenarios. The order parameter controls execution order when multiple hooks exist.

A: Three ways: (1) Tags — @smoke, @regression, custom tags. Use -Dcucumber.filter.tags on the command line or the tags option in @CucumberOptions. Tag expressions support and, or, not operators. (2) Separate runner classes — SmokeRunner, RegressionRunner, each with different tag filters. (3) Features path — point to a specific feature directory. In CI/CD, I use tags: smoke runs on every commit, regression runs nightly.

A: glue specifies the Java packages where Cucumber looks for step definitions and hooks. If glue is wrong or missing, Cucumber cannot find your step definition methods and reports them as "undefined." You can specify multiple packages: glue = {"com.autopractice.stepdefinitions", "com.autopractice.hooks"}. Always include both your step definitions package and hooks package.

A: dryRun = true makes Cucumber validate that every step in your feature files has a matching step definition — without actually executing the tests. No browser launches, no Selenium runs. It prints undefined steps with suggested method signatures. I use it when writing new feature files to quickly check step coverage before implementing the automation. Set it back to false when ready to run.