Gate: feature-spec-match
Every scenario of the feature matches a rule the spec declares.
| Property | Value |
|---|---|
| Checker | feature-spec-match |
| Confronts | feature |
| Blocking by default — new project | yes |
| Blocking by default — existing project | no — informs |
How it measures
Section titled “How it measures”The forward gates of the unit walk from the origin to the destination: every rule needs a scenario, every scenario needs a test. Neither walks back from the destination to ask whether the origin still exists. The cost was measured: a revert deleted a rule from the spec, the code and the test, while the feature kept its scenario (a parallel change reintroduced it with no conflict). The scenario went on asserting a behaviour nobody decided any more, the test stayed green proving a rule nobody declared, and every gate was green.
This unit holds the return leg of each pair, as two gates of their own, so that whoever reads the accusation knows it is about the destination:
- feature-spec-match confronts a feature: does every scenario code of this unit correspond to a rule that a spec covering this feature still defines?
- test-feature-match confronts a test: does every code the test names correspond to a scenario that a feature it exercises still declares?
Both were tuned against false accusations measured in a real project, because a gate that accuses what is right teaches people to ignore it: numbered variants of one rule, data states defined by name, the visual baseline, revision codes, and other units’ codes cited to build fixtures are not orphans.
Declaring it
Section titled “Declaring it”gates: - name: feature-spec-match on: [feature] check: feature-spec-match