---
id: M07-L02
title: "Prove tests catch a meaningful defect"
module: M07
chapters: "15"
checkpoint: "CP07"
---

# M07-L02 — Prove tests catch a meaningful defect

Show that a behavioral test rejects an incorrect but compiling implementation. Use a disposable CP07 copy and preserve the good baseline. This lesson's mutation is a stale-boundary error, separate from the supplied FAULT-stale checkpoint that disables expiration entirely.

Read the requirement: a sample remains current at age 3000 milliseconds and becomes stale only beyond that boundary. In `Monitor::poll`, change only the expiration comparison from `>` to `>=`. Do not alter input validation or a different comparison. The seeded change is intentionally wrong and belongs only in the exercise copy.

```powershell
.\scripts\test.cmd
```

The bad version should compile and then fail the relevant equality assertions. If compilation fails because of a typing error, repair that accidental error before assessing the behavioral test. A compiler rejection does not establish that an assertion can distinguish the wrong boundary.

Read the failure location and connect it to the original requirement. The ordinary and rollover equality cases exercise the same freshness rule under different timestamps. Do not change expected values to match the faulty implementation. The independent contract is what makes the test useful.

Restore exactly the original comparison, rerun the same check, and inspect the diff. The good source must still pass. Save both results and distinguish the intentional fault from any accidental problem encountered while seeding it. If shared firmware source was changed, also reproduce the cross-build after restoration.

This small exercise is mutation testing in practical form: introduce a meaningful defect and ask whether verification rejects it. It does not prove every possible error will be detected. It demonstrates one specific capability of this suite and identifies a regression check worth preserving.

## Resources and completion

Read Chapter 15 and the matching Sensor Monitor checkpoint README, requirements, and evidence notes. Project paths are relative to its root. Figures: SS15-03, SS15-04. Attempt the [exercise](exercise.md), preserve actual results, then use the separate instructor answer key. 

Source resources: [Chapter 15](../../../../book/chapters/ch15/chapter.md); [checkpoint and recovery map](../../../../examples/sensor-monitor/docs/checkpoints.md). Use the README and requirements inside your named checkpoint; the repository's final CP09 files include features absent from earlier stages.