Writing test cases

“It works” usually means: it worked once, at 101 kPa, with all sensors. A test case records what the chip must do in a certain situation. With a handful of them you check in a minute after every change whether everything still holds.

Three kinds of test cases#

• Normal case: typical values that occur every day – 101.3 kPa in the hall.
• Edge case: exactly on the threshold and just beside it – 90.0 and 89.9 kPa. This is where mix-ups of slt and sle hide.
• Failure: sensor gone, value NaN, device missing. The chip has to go into the safe state.

The table of expectations#

Write the table before you program. For the pressure light of the hall it looks like this:

Every row is a question to the code. Whether “90 still counts as green” is right is decided only by sge or sgt:

define GRUEN_MIN 90   # kPa, green from here, 90 is included
define GRUEN_MAX 110  # kPa, green up to here, 110 is included
sge low p GRUEN_MIN
sle high p GRUEN_MAX
and green low high

The tests in the academy are exactly such tables: set values, run ticks, expect a result. In the game you do the same with a dial as test value – more on that in the big project.

After every change#

A small change to one limit can break a completely different line. That is why all test cases run after every change, not just the one you are working on. In the simulator that takes a minute, in the game after a failure it often takes an evening.