Gherkin — Background, Feature Tags and Hooks
A named Background whose two steps are prepended to all three scenarios, plus feature-level tags that every scenario inherits and scenario-level tags that only some carry. Tag filtering is where this file earns its keep: @slow selects one scenario by its own tag and all three by inheritance from the feature.
@checkout @slow
Feature: Cart persistence
Background: a signed-in shopper with an empty cart
Given a signed-in shopper "sample.user@example.com"
And an empty cart
@persistence
Scenario: The cart survives a page reload
When I add 1 of "NX-1042"
And I reload the page
Then my cart contains 1 item
@persistence @slow
Scenario: The cart survives signing out and back in
When I add 2 of "NX-2087"
And I sign out
And I sign back in as "sample.user@example.com"
Then my cart contains 2 items
@wip
Scenario: The cart merges with a guest cart
Given a guest cart containing 1 of "NX-1042"
When I sign in as "sample.user@example.com"
Then my cart contains 1 item
Specifications
- Seed
- 61200
- Encoding
- UTF-8
- Line Endings
- LF
- Gherkin Dialect
- en
- Scenarios
- 3
- Background Steps
- 2
- Feature Tags
- 2
- Scenario Tags
- 4
- Named Background
- true
- Total Steps After Expansion
- 16
Testing contract
Expected to pass- Scenario
- Resolve effective tags and step counts after Background and tag inheritance.
- Expected result
- All three scenarios inherit @checkout and @slow from the feature and start with the two Background steps, giving 5, 6 and 5 steps respectively.
What is a .feature file?
A .feature file holds a Gherkin specification: a business-readable, plain-text description of behaviour written as Feature, Background, Scenario, and Scenario Outline blocks whose steps begin with Given, When, Then, And, or But. Scenario Outlines are parameterised by an Examples table, and tags such as @smoke mark subsets of the suite. Cucumber, Behave, SpecFlow, and Behat all read the same grammar, with localised keyword sets available for non-English specifications.
How to use this file
Use an example .feature file to test Gherkin parsers, step-definition matchers, linters, and editor tooling — verifying tag inheritance, Scenario Outline expansion against the Examples table, docstring and data-table arguments, and behaviour on deliberately malformed keywords.
How to use this file for testing
“Gherkin — Background, Feature Tags and Hooks” is a deterministic Novus Examples fixture for Code parsing, Conversion testing, Editor testing. Short, known-correct source files in many languages with classes, functions, generics, enums, and error handling — for testing parsers, linters, formatters, language detection, and diff viewers.
Documented properties for this file: seed 61200 · UTF-8 · LF. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Test and coverage reports document their totals (suites, cases, passes, failures, skips, covered lines) in the spec table. Point your CI dashboard, coverage gate, or report converter at the file and assert those counts survive; format twins carry identical numbers so a conversion can be scored exactly.
Related files
- featureGherkin — Checkout Feature (Background, Outline, Doc String)The source feature for this whole group: a Background with a data table, a plain scenario, a Scenario Outline expanded by two Examples tables, and a scenario asserting against a doc string. It compiles to exactly six pickles and 32 pickle steps — the numbers the cucumber-messages and cucumber.json twins next to it report.
- robotRobot Framework — Checkout SuiteA complete Robot Framework suite with all four common sections, scalar, list and dictionary variables, a continued line using ..., and user keywords with arguments. Robot separates arguments on two or more spaces, so a parser splitting on a single space merges every keyword call into one token.
- robotRobot Framework — Data-Driven Test TemplateThe template form, in which the *** Test Cases *** header itself names the argument columns and each row becomes one test. Five tests share a single keyword body, and a parser that reads the header row as a test name reports six.
- robotRobot Framework — Shared Keyword ResourceA resource file: keywords, variables and imports with no *** Test Cases *** section at all, meant to be imported by the suites next to it. Tooling that requires at least one test case rejects a perfectly ordinary resource, and keyword defaults such as ${qty}=1 are where argument parsers usually stop.
- xmlCoverage — Clover XMLThe Clover serialisation, whose <metrics> element rolls statements, conditionals and methods into a single elements/coveredelements pair. Anything reading only that pair reports a blended percentage that matches none of the other three formats unless the components are separated first. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.
- xmlCoverage — Cobertura at Zero CoverageA structurally complete Cobertura report in which line-rate and branch-rate are 0.0 everywhere. The counterpart to the zero-coverage LCOV file, for checking that a converter keeps the class and method structure when there is nothing covered to describe.
Generated by generation/testing.py. Free for any use, no attribution required — license.