Using Cucumber Scenario Outline to Drive Data‑Driven BDD Tests

Problem: Repeating Similar Scenarios

When writing behavior‑driven tests you often need to verify the same rule with different inputs. For example, a login feature might need to be checked with several username/password pairs. Writing a separate scenario for each pair leads to duplicated Gherkin steps, makes the feature file hard to read, and increases maintenance effort when the underlying step definitions change.

Thesis: Scenario Outline Provides a Compact, Executable Template

Cucumber’s Scenario Outline lets you define a single scenario template with placeholders enclosed in angle brackets (< >). An accompanying Examples table supplies concrete values for each placeholder. Cucumber treats every row in the table as an independent scenario execution, reporting results per iteration. This approach keeps the feature file concise while preserving the clarity of individual test cases.

Worked Example: Login Validation

Consider a feature that validates login credentials. The step definitions already exist for entering a username, entering a password, clicking the login button, and checking for an error message.

Feature: Login validation

  Scenario Outline: Invalid login shows error
    Given I am on the login page
    When I enter '' as username
    And I enter '' as password
    And I click the login button
    Then I should see the error message ''

    Examples:
      | username    | password   | expectedMessage          |
      | alice       | wrongpass  | Invalid credentials      |
      | bob         | 12345      | Invalid credentials      |
      | charlie     | !@#$%      | Invalid credentials      |

Each row in the Examples table binds its values to the placeholders , , and . When you run the feature, Cucumber creates three separate scenario executions, one per row.

Verification Steps

1. Save the above content to a file named login.feature in your project’s src/test/resources directory.
2. Ensure you have Cucumber‑JVM (version 1.0 or newer) or Cucumber‑JS (version 0.5 or newer) configured in your build.
3. Run the test suite:
   • For Maven: mvn test
   • For npm: npx cucumber-js
4. Inspect the console output or a JSON report. You should see three iterations, each labeled with the row values (e.g., "username=alice, password=wrongpass, expectedMessage=Invalid credentials").
5. To confirm proper failure reporting, change the expectedMessage in the second row to something that will not match the actual output (e.g., "Account locked") and rerun. The report should indicate that the second iteration failed while the first and third passed.

Trade‑Off and Limitation

Scenario Outline shines when the data set is modest—typically fewer than a few dozen rows. Large tables (hundreds or thousands of rows) increase suite startup time because Cucumber must instantiate a scenario for each row before execution begins. The console or report output also becomes verbose, making it harder to locate a specific failure. In such cases consider:

• Splitting the data into multiple feature files or separate Scenario Outlines.
• Using external data sources (CSV, JSON, or a database) and reading them within a step definition, keeping the Gherkin lightweight.

Actionable Closing

Start by identifying a rule in your application that you need to validate with several input combinations. Replace the duplicated scenarios with a single Scenario Outline, add an Examples table, and run the suite to verify that each row produces its own test result. Keep an eye on the table size; if it grows beyond a few dozen rows, evaluate external data feeding to maintain fast feedback and readable reports.