How does parameterizing a step definition stop the glue layer growing one definition per sentence?

The glue layer's characteristic failure is growth in the wrong dimension: a library that grows with the number of *sentences written* instead of the number of *behaviors the product has*. **Parameterization** is the main tool against it. ## Why sprawl happens It is not laziness so much as a path of least resistance built into the tooling: 1. Someone writes a new scenario, runs it, and the runner reports the new line as undefined and helpfully prints a skeleton definition. 2. Pasting the skeleton takes seconds; opening the existing library, finding the near-identical definition, and generalising it takes minutes and touches code other scenarios depend on. 3. Repeat that a few hundred times and the arithmetic gets ugly. A timetable-planner suite that had grown this way carried 418 step definitions for 96 scenarios — more than four definitions per scenario, which means almost every line ever written got its own function. After consolidation it held 63, and the suite exercised exactly the same behavior. **The ratio of definitions to scenarios is the cheapest health signal you have**; a mature library trends toward far fewer definitions than scenarios, because scenarios reuse. ## One definition per behavior The rule to state in an interview is that a definition corresponds to a *behavior of the product*, not to a *string of text*. "A course is scheduled into a period" is one behavior. `"Year 9 Maths" into Tuesday period 3` and `"Year 11 Physics" into Thursday period 1` are two instances of it. So the pattern captures course, day and period, and one function serves both — and serves every future row of examples anyone adds without a line of new glue. ## Placeholders and typed parameters - **Basic placeholders** capture a number, a quoted string, or a single word and hand them over already converted, so the function signature reads like a domain operation rather than a parse. - **Custom parameter types** are the step up: you register once that the text `Year 9 Maths` resolves to a `Course` object, and from then on every definition using that placeholder receives a `Course`. The conversion, the lookup, and the "no such course" error message live in one place instead of being re-implemented in twenty definitions. This is also what keeps definitions thin — a definition that begins with five lines of turning text into objects has swallowed a job that belongs in a parameter type. ## Wording variation without extra definitions Alternation and optional-text markers in a step expression let one pattern absorb "a teacher"/"the teacher", singular/plural, and a trailing clause that some sentences carry and others do not. Used in moderation this removes a whole class of duplicate definitions that exist purely because two authors punctuated differently. Used immoderately it produces patterns nobody can read, which is the next hazard. ## Over-parameterizing is a real failure too A pattern of the shape "the user does <anything>" matches everything, which makes it a magnet for ambiguous matches and makes the library impossible to reason about — you can no longer tell from a sentence which function will run. Two smells mark the line: - First, a **catch-all wildcard** where a typed placeholder would do. - Second, **parameter count**: a definition taking five or six arguments has stopped being a sentence and become a function call written in prose, and it usually wants splitting or a table argument instead. A useful reflex is to parameterize the *values* a behavior varies over and to leave the *behavior itself* in the literal text of the pattern. ## Where duplication should go instead Definitions should be one to three lines: convert arguments into a call on a helper or driver, or assert on what a helper returns. When two definitions genuinely need the same twelve lines of setup, that setup moves into the helper layer. - **Duplication in helpers** is ordinary code duplication and can be refactored freely; - **duplication in the step library** is duplication in a shared, text-addressed namespace where any change risks breaking scenarios nobody in the room has read. ## Ownership when the library is shared Once several teams load the same glue, **a phrase becomes an interface**. Adding a placeholder to an existing pattern is a compatible change if the old sentences still match, and a breaking one if they do not — the failure surfaces as an undefined step in someone else's suite. Teams that share a library therefore need a named owner for the phrase set and a habit of grepping the whole corpus before generalising a pattern, exactly as they would before changing a published signature.