gherkin-automationlisted

# Automating Gherkin ## Overview A step definition is a translation layer, and its whole job is to be thin. It takes one business statement, converts it into a call on something that already knows how to do the work, and gets out of the way. Suites become unmaintainable when step definitions grow into the application driver instead of calling one. The rules below are the same in every runner. Language-specific notes live in the reference files. ## When to use this skill - Writing the code behind new or existing steps. - A step is undefined, pending, or ambiguous. - A scenario is flaky, or the glue prevents running in parallel. - State is being passed between steps badly, usually through globals. - Test data setup has become the biggest part of the suite. - Deciding whether a case belongs in Gherkin at all. If the scenarios themselves read as click-by-click scripts, no amount of glue design will save the suite; fix the wording with the review skill first. ## The layering rule Three layers, and each may only call the one below it. 1. **Step definitions.** Parse the step, call one task, assert nothing beyond what the step says. A handful of lines. 1. **Task layer.** Domain-shaped operations in the language of the business: register a member, borrow a title, run the overnight renewal. This is where the knowledge of how to do things lives. 1. **Driver layer.** Page objects, API clients, message publishers, database fixtures. The only place that knows about sel