Gate: feature-test-match

Every scenario of the feature is implemented in the linked test, by code and by description.

Property	Value
Checker	feature-test-match
Confronts	feature
Blocking by default — new project	yes
Blocking by default — existing project	no — informs

How it measures

Confronts the relational edge between a feature file and the test file that executes it: every scenario catalogued in the feature must be implemented in the linked test.

The gate enforces a critical TWO-TIER VERDICT:

1. BY CODE (Defect / Failure): Every scenario code (XXXXX-Y##) must appear in the non-comment body of at least one linked test. A missing scenario code is a DEFECT indicating that an agent or developer skipped the scenario entirely or renamed the code without updating the test. When code is missing, the gate returns a blocking Fail.
2. BY DESCRIPTION (Signal / Warning): When the scenario code exists in the test, the gate checks whether the test description corresponds to the scenario title. Free-form text naturally varies between human domain language in Gherkin (“when description and value are identical”) and code identifiers in tests (classifica, expect). Therefore, descriptive drift is treated as an informative SIGNAL rather than a hard failure: the gate issues a non-blocking Pending warning so teams can realign descriptions without blocking delivery of verified code.

Neighbouring gates govern other dimensions of the unit: unit-complete checks the physical presence of the unit artifacts; spec-feature-match ensures requirements defined in specs are covered by feature scenarios. feature-test-match specifically guarantees that documented scenarios are faithfully realized in automated test suites.

Declaring it

gates:
  - name: feature-test-match
    on: [feature]
    check: feature-test-match

Source: checker · its spec