ears-tests

name

ears-tests

description

Generate parameterized (table-driven) tests from EARS requirement statements — the deterministic transform that turns an SBCE capability spec's `## Requirements` into one parameterized test per requirement group and one labeled row per statement id. Stack-neutral; owns only the EARS→table mapping and the spec↔test trace, and delegates the test syntax to the composed stack skill (JUnit 5, zunit, Playwright). Use whenever turning EARS requirements, acceptance criteria, or an SBCE/`/sbce` spec into tests; whenever you see "When/While/If…then, the … shall …" statements that need covering; or when asked for table-driven, data-driven, or parameterized tests from a requirement group. Triggers on "EARS", "parameterized tests", "table-driven tests", "data-driven tests", "tests from requirements", "tests from the spec", "cover requirement Rn", "generate tests for this capability", "acceptance criteria to tests".

Turn EARS requirement statements into parameterized tests. The leverage is structural: every EARS pattern is a (condition → response) tuple, and an SBCE requirement group already collects statements that share one boundary operation — same arrange/act skeleton, only the data differs. That is the textbook precondition for parameterization, so the mapping is mechanical.

Own only the transform and the trace. The concrete test syntax is the composed stack skill's call — never name a runner or framework verb here. When the generated tests exercise the running system, the system-tests skill owns the contract (black box, coordinates as configuration, total verdict reporting).

The mapping

• One requirement group Rn → one parameterized test method (the shared boundary op is the body).
• One statement Rn.m → one row in the parameter source.
• The statement id Rn.m is the row's display name — so the spec↔test binding stays per-statement and grep-visible, exactly as SBCE requires (a removed id retires its row; a row with no statement is drift).