Cucumber-JVM 7 and Behave both support Scenario Outlines with multi-column Examples tables. Most teams reach for them the moment they see two scenarios that differ only by data — which is exactly the right instinct. The problem surfaces six months later when a single step regex is doing six different jobs, the step documentation is unreadable, and a one-line domain change requires touching fourteen files.

The mechanism is subtle: every <placeholder> you add to a step title is a silent contract between the feature file and every step binding that matches it. Add a second column to the table and you haven't just added test cases — you've potentially forked the execution path inside the binding, introduced conditional logic that belongs in the domain layer, and made the step living documentation worthless because the rendered step text is a template, not a sentence.

This article walks through exactly how that proliferation happens, how to detect it before it compounds, and how to restructure outlines so that parameterization stays in the data layer — not the binding layer. By the end you'll have a concrete refactoring pattern and a lint rule you can drop into CI today.

What Scenario Outline Tables Actually Bind At Runtime

A Scenario Outline is syntactic sugar. At parse time, Cucumber expands each row in the Examples table into a fully materialized scenario. The step text — with placeholders substituted — is then matched against the registered step definition pool exactly as if you had written N separate scenarios by hand. The binding doesn't know it came from a table; it sees a concrete string. This means every unique combination of placeholder values that produces a distinct regex match is, effectively, a distinct execution contract.

Where this matters architecturally: if your step binding contains a branch on the substituted value (if amount == "0" then ...), you've moved domain logic into the glue layer. The step is no longer a thin adapter between Gherkin and your application driver — it's a decision node. That's the root cause of brittleness. When the domain changes, the binding changes, and because the binding is shared across every row in the table, the blast radius is the entire outline. Teams that rely on shared step libraries feel this especially hard: one conditional added to a common binding can silently alter behavior for dozens of unrelated scenarios.

Detecting and Refactoring the Binding Proliferation Pattern

Start with detection. The fastest signal is cyclomatic complexity on your step definition files. In a Python/Behave project, run radon cc -s steps/ --min B — any step function scoring B or above almost certainly contains branching on a substituted parameter. In a Cucumber-JVM project, SpotBugs or SonarQube's complexity rules will surface the same pattern. A healthy step binding is a straight line: parse the argument, call the driver, assert or store state. Anything else is a smell.

Here's a canonical example of the anti-pattern. The feature file looks clean:

Scenario Outline: Apply discount code
  Given a cart with <item_count> items totalling <subtotal>
  When the user applies discount code "<code>"
  Then the order total should be <expected_total>

  Examples:
    | item_count | subtotal | code       | expected_total |
    | 1          | 50.00    | SAVE10     | 45.00          |
    | 3          | 120.00   | FREESHIP   | 120.00         |
    | 0          | 0.00     | SAVE10     | 0.00           |

But the binding that grew to support it looks like this:

# Python / Behave
@when('the user applies discount code "{code}"')
def step_apply_discount(context, code):
    if code == "FREESHIP":
        context.cart.apply_shipping_waiver()
    elif code.startswith("SAVE"):
        pct = int(code.replace("SAVE", ""))
        context.cart.apply_percentage_discount(pct)
    else:
        context.cart.apply_code(code)  # fallback — undefined behavior

The if/elif/else tree means this one binding encodes three different domain operations. Adding a new discount type — say, BOGO — requires editing the binding, not just adding a row to the table. The step write contract is broken: the Gherkin says "applies discount code" but the binding actually routes to three different application methods. Fix this by pushing the routing into the application layer and keeping the binding dumb:

# Refactored — binding is a thin adapter
@when('the user applies discount code "{code}"')
def step_apply_discount(context, code):
    context.cart.apply_code(code)  # domain layer owns the routing

Now CartService.apply_code() owns the discount logic. The step binding is stable regardless of how many rows the table grows to. Run time impact is negligible, but maintenance cost drops sharply: in one real migration of a 400-scenario Behave suite, collapsing 11 branching bindings into 11 thin adapters reduced the step definition count by 34 and cut the average time-to-diagnose a failing scenario from ~8 minutes to under 2, because stack traces no longer bottlenecked inside conditional glue code.

For TypeScript/Playwright with Cucumber.js, the same principle applies but the detection tooling differs. Add an ESLint rule targeting step definition files:

// .eslintrc.js — flag switch/if inside step definitions
"rules": {
  "complexity": ["error", { "max": 3 }]
}

Wire this into your GitHub Actions workflow so it runs before the test suite itself:

# .github/workflows/ci.yml
- name: Lint step definitions
  run: npx eslint 'src/steps/**/*.ts' --max-warnings 0
- name: Run BDD suite
  run: npx cucumber-js --profile ci

This makes complexity regressions a build failure, not a code review footnote. The relationship between step definition count and maintenance cost is roughly linear up to about 150 bindings, then superlinear — catching the branching pattern early keeps you on the linear side of that curve. Also worth noting: AI-assisted step write tools like Cursor or GitHub Copilot will happily generate the branching anti-pattern because they pattern-match on existing bindings in your repo. If your existing bindings already contain conditionals, the generated steps inherit that stale vocabulary and compound the problem rather than fixing it.

Where Senior Engineers Still Get Tripped Up

The most common mistake is treating the Examples table as a test matrix rather than a data fixture. When columns represent fundamentally different behaviors — not just different values for the same behavior — the outline is the wrong abstraction. Separate scenarios with explicit names communicate intent far better than a six-column table where two of the columns are boolean flags controlling execution paths. The org-level pressure here is real: product managers love seeing "we cover 40 cases" in a single outline, but that number is meaningless if the binding is a decision tree.

A second failure mode is overloading a single outline to cover both happy-path and error-path rows. Error cases usually require different assertion logic, which means the binding ends up with a conditional on an expected_error column. Split them: one outline for success paths, a separate scenario (or outline) for each error class. This also improves step living documentation output — tools like Cucumber Reports and Allure render each row as a named test case, and "applies discount code — row 7" is not a useful test name. Explicit scenario names are.

Myths About Outlines That Persist in Mature Codebases

Myth 1: More rows means better coverage. Table rows multiply execution paths through the same binding — they don't broaden coverage unless each row exercises a distinct domain rule. Fifty rows that all hit the same code path add CI time without adding signal. Coverage breadth comes from scenario diversity, not row count. Use a coverage tool (Istanbul, Coverage.py, JaCoCo) to verify that adding rows actually exercises new branches in the application code, not just the glue layer.

Myth 2: Outlines are the idiomatic way to write parameterized BDD. They are one way. For data-heavy scenarios, a direct call to a parameterized test harness (Pytest's @pytest.mark.parametrize, JUnit 5's @ParameterizedTest) with a thin Gherkin wrapper for the human-readable contract is often cleaner. Reserve Scenario Outlines for cases where the Gherkin sentence itself needs to be readable by non-engineers — that's their actual value proposition. When the audience is purely technical, the overhead of maintaining the outline/binding contract may not be justified. Teams that treat scenario tags as a selection policy often make the same category error: reaching for a BDD mechanism because it exists, not because it fits the communication need.

If you implement the complexity lint rule and the thin-adapter refactoring pattern described here, the next metric worth tracking is mean-time-to-diagnose on failing outline rows — specifically, how long it takes an engineer unfamiliar with the scenario to identify the root cause from the stack trace alone. That number is a direct proxy for binding health. For teams using AI-assisted step generation, also audit generated bindings weekly; tools like Cursor will regenerate the branching pattern unless your existing codebase demonstrates the thin-adapter style consistently.

Note: This article is for informational purposes only and is not a substitute for professional advice. If you need guidance on specific situations described in this article, consider consulting a qualified professional.