How Can You Test a Sensor Spike Rule?
From the earlier reference collection. Read the current software blog.
Use ordinary, threshold, and extreme readings to pin down exactly which values trigger a spike flag.
Write down the rule first
A spike rule needs a defined comparison before test values can be chosen. It might flag an absolute change from the previous reading, a rate of change over elapsed time, or a value outside a statistical range. Those methods answer different questions. Record the inputs, units, time assumptions, and whether equality at the threshold counts as a spike.
For a simple absolute-change rule, suppose the configured limit is ten units between successive readings. A change of four should remain ordinary; a change of twelve should be flagged. The example only makes sense if readings use the same unit and the time gap is within the rule's intended scope.
Test the exact boundary
If the rule says a change greater than ten is a spike, then exactly ten should not be flagged, while a slightly larger change should. If it says greater than or equal to ten, the expected result changes. Include both sides of the threshold and the exact threshold so a one-character comparison change cannot slip by.
For a rate-based rule, hold the change constant and vary the elapsed time, or hold time constant and vary the change. This proves the implementation uses the intended denominator instead of accidentally comparing raw differences.
Include extreme and unusable inputs
Test a very large value, a negative reading if the sensor's domain permits it, and a missing or invalid value. Decide whether extremes should always flag, be rejected as invalid, or pass through to a separate quality-control state. A missing reading should not be coerced to zero and create a false spike.
Check the first reading in a sequence, which has no predecessor for a change-based rule. It should follow a documented initialization policy rather than comparing against an implicit zero.
Check the flag's consequence
Assert not only the boolean flag but the resulting behavior: whether the reading is annotated, excluded from an aggregate, or retained with a warning. A spike detector should not silently erase source data unless that is its explicit role. Keep raw and interpreted values distinct where later review may matter.
A small set of ordinary, boundary, extreme, and missing cases defines the rule in operational terms. When the threshold or policy changes, update the fixture and its explanation together.