Writing assertions is half the job. The other half is living with them: decoding failures, distrusting green suites, keeping regressions quiet, and placing checks where they survive.
Symptom | The question | Lesson |
|---|---|---|
An assertion fired | Is the RTL wrong, or my assertion? | Debugging failures: start time, fail time, sampled values |
An assertion is silent | Is it passing, or never trying? | Vacuity and coverage: a cover on every antecedent |
The regression is slow or noisy | Which checks cost the most? | Performance and noise: precise antecedents, bounded windows |
Where should it go? | Who owns it, and does it survive synthesis? | Placement: inline, interface, bound checker |
Sign-off | Is every check actually checking? | The review checklist |
Lesson | What it covers | Path |
|---|---|---|
Attempt start vs fail time, the preponed off-by-one, and sampled action-block messages. | Required | |
Vacuity audits, assert and cover pairs, and cover-first development. | Recommended | |
Attempt cost, bounded liveness, phase control, and readable regressions. | Optional | |
Inline, interface, and bound checkers, plus synthesis and formal reuse. | Recommended | |
Six review checks applied to a flawed module, with a repaired version. | Recommended |
Required lessons are the core first pass for writing working assertions. Recommended lessons are worth reading for most learners once the first pass works. Optional lessons are reference, specialist material or revision, and you can come back to them when a project needs them.
A failing check may be disabled by a scoped control that was never re-enabled, and a passing implication may be vacuous: its antecedent never fired, so the consequent was never examined. Both need cover and vacuity data to rule out.