Gherkin Flow

The problem

A Gherkin scenario fails, and now the real work starts: scroll through Maven, npm, or Behave output to find which step broke, copy the error, search across Java, TypeScript, or Python files by hand, fix it, switch back to the terminal, and re-run the whole suite to find out if it worked — ten times a day. Writing scenarios carries its own tax too: minutes spent duplicating step definitions that already exist, and scenarios that ship with no assertion because nothing caught it in review.

What it does

Gherkin Flow keeps the whole loop inside the feature file. Run buttons sit above every scenario — no terminal required — and a failure shows up as inline ghost text on the exact step that broke, with per-step timing in the Testing panel. An AI-driven linter flags weak or incomplete scenarios before they reach review, and GherkinFlow: Generate Scenarios from Description turns a plain-English requirement into a complete .feature file. Undefined steps are underlined before you even run, with autocomplete against existing step definitions.

Zero config where it matters

JavaScript and TypeScript (cucumber-js) and Python (Behave) are detected and configured automatically — no settings.json changes. Java needs one JSON reporter line on the Cucumber runner class; Gherkin Flow then scopes the run to that runner specifically (-Dtest=<Runner> for Maven, --tests <Runner> for Gradle) so running one scenario doesn’t drag the whole unit and integration suite along with it. Monorepos work the same way — each feature file resolves to its own nearest build root.

Under the hood

A VS Code extension written in TypeScript against the editor’s native Testing API, with reporters bridging cucumber-js, Cucumber-JVM, and Behave into the same step-level view regardless of which language wrote the test.