Big project: testing

Five chips, twenty interfaces, a hundred devices. Whoever switches everything on at once and watches whether it works is looking for a needle in a haystack when something fails. That is why testing happens in three stages – from small to big.

Stage 1: subsystems one by one#

Every sub-chip is tested on its own, in the simulator and with its test cases. Instead of the central unit you set its inputs by hand: the setting of the housing, the Logic Memories of the interface. If a subsystem does not run on its own, it will not run in the network either.

Stage 2: the interplay#

Then two chips come together that share an interface – central unit and life support, for example. Only what flows between them is checked: does the request arrive? Does the status come back? Do the versions match? Only when every pair works does the next one join.

Stage 3: failure tests#

Finally things are broken on purpose: remove a sensor, cut a data cable, remove a Logic Memory, pull a chip. For every failure the table of expectations says what must happen. In the game you do that with a wrench and a welder, in the simulator with “remove”.

A test mode in the game#

Some things are hard to bring about in the game: you want to see whether the hall heating starts at 15 °C, but the hall is at 25 °C. A test mode helps. A lever switches over, a dial then provides the value instead of the sensor:

lbn test HEBEL HASH("Testmodus") Open Average
sgtz test test                      # missing lever: no test mode
lbn value DREHKNOPF HASH("Testwert") Setting Average
add value value CELSIUSOFFSET
select temp test value temp         # in test mode the dial counts

The control below stays unchanged – what gets tested is exactly the code that later runs in normal operation too. A light shows that the test mode is active so it does not stay on by accident.