defining-test-scenarios

To generate test scenarios from behavioral specs, expand a single feature ID into deterministic GIVEN-WHEN-THEN scenarios. This approach ensures downstream test-writing agents receive unambiguous acceptance checks without making behavioral decisions.

The best way to write deterministic GIVEN-WHEN-THEN tests is to enforce observable outcomes only and use deterministic entity placeholders. This guarantees scenarios remain implementation-agnostic and strictly scoped to the feature ID.

To ensure generated test scenarios are implementation-agnostic, enforce constraints like no source-code reading and no architecture assumptions. Scenarios must only specify observable outcomes and deterministic entity labeling.

Yes, you can expand a single feature ID from a behavioral spec into a complete test suite. The process produces a dedicated specs/{spec-name}.test.{FXX}.md file containing precise scenarios and a Coverage Summary for traceability.

To handle assumptions and cross-feature traceability in test generation, flag and encode [ASSUMPTION] behaviors directly within the scenarios. Additionally, include cross-feature traceability notes and produce a Coverage Summary.

Yes, spec-driven test generation works without reading source code. It bridges the gap between system behavior and acceptance checks by enforcing non-code constraints, relying exclusively on observable outcomes from the behavioral spec.