Gherkin Editor and Linter (Cucumber Feature Files)

About the Gherkin Editor and Linter (Cucumber Feature Files)

An editor for Cucumber’s Gherkin files with syntax highlighting, line numbers and a linter that catches what reviewers usually point out: scenarios without a When or a Then, steps outside a scenario, Given after When, duplicate scenario names, Scenario Outlines whose Examples columns do not match their <placeholders>, very long scenarios, a misspelled step keyword and inconsistent tags. Parse errors show their line and column as you type.

Next to the editor you get the file formatted in the standard layout (aligned tables, two-space indents, comments kept), the outlines expanded into the scenarios that actually run, the keywords translated into another of Gherkin’s languages — 33 of them, including Hindi, Marathi, Gujarati, Punjabi, Tamil, Telugu, Kannada, Malayalam, Urdu and Nepali — and step-definition skeletons for Cucumber-JS, Java (Cucumber-JVM), Python (behave) and Ruby, with {int}, {float} (or Java’s {double}) and {string} parameters worked out from your steps.

Without a pass the result is a free preview: your file, its syntax errors and every count, with the first problems and the first lines of each generated file. The full lists and copying or downloading them unlock with a Pro pass; opening and saving your own .feature files always works. Everything runs in your browser.

Common uses

• Reviewing feature files before a pull request, without setting up an IDE plug-in.
• Teaching or learning BDD: see how outlines expand and which steps need code.
• Starting the step definitions of a new feature in JavaScript, Java, Python or Ruby.
• Writing feature files in Hindi or another language for a team that reads it best.

What the linter checks

• Structure: one Feature per file, a Background before the first scenario, steps only inside a Background or scenario, Examples only after a scenario’s steps, tables with the same number of cells in every row, closed doc strings (parse errors, with line and column).
• Each scenario: a When step (the action) and a Then step (the outcome); no Given after a When or Then; no second When after a Then (one behaviour per scenario); no And or But as the first step; at most 10 steps (you can change the limit); a name, unique within its Feature or Rule.
• Outlines: every <placeholder> has an Examples column, every column is used, Examples have rows; a placeholder in a plain scenario is pointed out.
• Backgrounds only set the scene: When and Then steps there are flagged.
• Tags: the same tag in different case, a tag repeated on one element or already given by its Feature or Rule, and a tag that every scenario carries (it can go on the Feature).
• Typos: a description line under a scenario that starts like a misspelled step keyword (“Gven”).

Gherkin, briefly

From Cucumber’s Gherkin reference: a file holds one Feature; Rule groups scenarios of one business rule; Background steps run before each scenario of its Feature or Rule; a Scenario (or Example) is a list of steps — Given sets the context, When is the action, Then the expected outcome, And and But continue the step before, and * can replace any of them. A Scenario Outline runs once per row of its Examples, with <name> replaced by that row’s value. Step arguments are doc strings (between """ or three backticks) and data tables (| cells; \|, \n and \\ escape a pipe, a new line and a backslash). Comments start a line with #; # language: hi on the first line selects a keyword language. Keywords are not part of matching a step to its code: Given, When and Then only tell the reader what a step is for.

Step definitions

Each distinct step becomes one skeleton, after outlines are expanded, as Cucumber itself does. Numbers become {int} or {float} ({double} in Java, as Cucumber-JVM’s own snippets write decimals) and quoted text {string} (Cucumber Expressions); the step text is taken without the spaces after its keyword, as Cucumber matches it; the characters (, { and / that would otherwise be read as optional text, parameters or alternatives are escaped. Doc strings and tables add a docString or dataTable parameter. For behave, steps use its default parse patterns — {n:d} for whole numbers, {x:f} for decimals, "{text}" for quoted text — and the table and doc string are in context.table and context.text; behave keeps Given, When and Then steps apart, so the same sentence under two keywords gives two functions. Java uses the English annotations, which match steps in any language.

Keyword languages

The editor knows 33 of Gherkin’s keyword languages, copied from the Cucumber project’s list (MIT licence): English, Hindi, Marathi, Gujarati, Punjabi, Tamil, Telugu, Kannada, Malayalam, Urdu, Nepali, Arabic, Chinese (simplified and traditional), Czech, Dutch, French, German, Hebrew, Indonesian, Italian, Japanese, Korean, Persian, Polish, Portuguese, Russian, Spanish, Swedish, Thai, Turkish, Ukrainian and Vietnamese. Translated replaces each keyword with the target language’s own word for it (the first one it lists, or the one in the same place of its list); the step text is left alone.

Limitations

• Gherkin has more than 70 keyword languages; this editor reads the 33 listed above and names the others it does not know.
• The linter checks the file, not your step definitions: it cannot tell which steps already have code.
• Step-definition skeletons are a starting point: rename the parameters and pick other parameter types where they fit better.
• Comments are kept by the formatter, placed above the line that followed them.

Privacy

On this device: nothing is sent

Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.