Testfälle schreiben

„Läuft doch“ heißt meistens: Es lief einmal, bei 101 kPa, mit allen Sensoren. Ein Testfall hält fest, was der Chip in einer bestimmten Lage tun muss. Mit einer Handvoll davon prüfst du nach jeder Änderung in einer Minute, ob noch alles stimmt.

Drei Arten von Testfällen#

• Normalfall: typische Werte, wie sie jeden Tag vorkommen – 101,3 kPa in der Halle.
• Grenzfall: genau auf der Schwelle und knapp daneben – 90,0 und 89,9 kPa. Hier verstecken sich die Verwechslungen von slt und sle.
• Ausfall: Sensor weg, Wert NaN, Gerät fehlt. Der Chip muss in den sicheren Zustand.

Die Tabelle der Erwartungen#

Schreib die Tabelle, bevor du programmierst. Für die Druckampel der Halle sieht sie so aus:

Jede Zeile ist eine Frage an den Code. Ob „90 gehört noch zu grün“ stimmt, entscheidet allein sge oder sgt:

define GRUEN_MIN 90   # kPa, ab hier gruen, 90 gehoert dazu
define GRUEN_MAX 110  # kPa, bis hier gruen, 110 gehoert dazu
sge unten p GRUEN_MIN
sle oben p GRUEN_MAX
and gruen unten oben

Die Tests in der Akademie sind genau solche Tabellen: Werte setzen, Takte laufen lassen, Ergebnis erwarten. Im Spiel machst du dasselbe mit einem Drehknopf als Testwert – dazu mehr im Großprojekt.

Nach jeder Änderung#

Eine kleine Änderung an einer Grenze kann eine ganz andere Zeile kaputt machen. Deshalb laufen nach jeder Änderung alle Testfälle, nicht nur der, an dem du gerade arbeitest. Im Simulator dauert das eine Minute, im Spiel nach einem Fehler oft einen Abend.