Tests

... sind zweifellos auch kein beliebtes Thema, aber notwendig!

Natürlich gibt es immer Besseres und Spannenderes zu tun, als Testfälle zu schreiben! Testfälle sind mit Aufwand verbunden, jedoch ermöglichen sie erst ein Debugging. Die Wahrscheinlichkeit, dass ihr es schafft, Code einfach herunterzuschreiben, ohne dabei auch nur einen einzigen Bug zu verursachen ist schon alleine aufgrund der Komplexität eines Projektes nahe NULL. Selbst wenn ihr im Team alle schon sehr erfahren seid.

Tests

• Wie man Testfälle schreibt ist, ebenfalls auf inf-schule.dedokumentiert.
• Bei Testfällen sollte man nicht nur ausprobieren, ob die fragliche Methode das tut was sie soll, sondern (vor allem) ob sie das nicht tut, was sie nicht tun soll.
• Beim Bauernschach sollte die Syntaxprüfung zwar gültige Eingaben durchwinken, aber vor allem ALLE ungültigen Eingaben erkennen.
• Dazu muss die Methode auf jede erdenkliche (oder syntaktisch vergleichbare) ungültige Eingabe getestet werden!
• Denkt dabei auch daran, was passieren würde, wenn eine ungültige Eingabe an das Backend übergeben würde.
• Vielleicht stürzt die Software nur ab, im schlimmsten Fall würde durch gezielte, falsche Eingaben Schummeln ermöglicht.
• Auch Testfälle kann man bereits schreiben, BEVOR man eine Methode implementiert, hinterher gibt es immer Besseres und Spannenderes zu tun.
• Das kann sogar bei der Implementierung hilfreich sein (Zeitersparnis!), weil die Aufgabe einer Methode vorher klarer definiert wird.
• Eure Testfälle könnt bzw. solltet ihr mit anderen Teammitgliedern besprechen, vier Augen sehen mehr als zwei.

Aufgabe 1

Die Macht von Bugs ist nicht zu unterschätzen! Recherchiert nach dem Bug in der Steursoftware der Ariane 5 Rakete, welcher eine Explosion verursacht hat.

Aufgabe 2

Denkt bei der Entwicklung daran, wann immer ihr codet, auch UMFANGREICHE Testfälle zu erstellen und diese für Debugging zu nutzen.