What it does
Designs, reviews, and strengthens developer-owned component tests in isolation, derives cases with black-box plus white-box techniques, and measures statement/branch coverage.
When to use it
When you need unit/component test guidance and structural coverage at the component level; before or during development of a unit.
Prerequisites
qa.config.yml; a unit runner from tooling.unit (or inferred from package.json and confirmed); paths.tests_dir; risk_areas to set the coverage target.
Output
Component test procedures / automated test scripts (ISO/IEC/IEEE 29119-3 Test Procedure Specification) plus a statement/branch coverage report, under paths.tests_dir.
Mechanics
How it works
- Read config and resolve the unit runner from tooling.unit
- Resolve the target component from arguments (or default to risk_areas.critical)
- Test the unit in isolation using test doubles (stubs/mocks/fakes)
- Derive cases with black-box (EP, BVA, decision table) and white-box statement/branch coverage
- Set the coverage target from risk_areas (branch for critical, statement floor otherwise)
- Implement/extend tests, run with coverage enabled, report counts and remaining gaps
Why it works
The theory behind it
The component test level (CTFL §2.2). Cases from black-box techniques (§4.2) plus white-box statement/branch coverage (§4.3) — the level where white-box coverage is meaningful. Coverage is a guardrail, not a vanity metric (Principle 7).
CTFL v4.0 §2.2 · §4.2 · §4.3
Example
See it in use
> /qa:unit-test "src/pricing/discount.ts"✓ Correct when It targets statement/branch coverage with test doubles and isolates the unit.