Ich schreibe gerade selbst Tests im Praxisprojekt und ergänze noch drei Begriffe, die bei uns in der Klausur direkt nach den Teststufen dran waren.
1. Die Testpyramide. Sie beschreibt, wie viele Tests man auf welcher Ebene haben sollte: unten viele Unit-Tests (schnell, billig, genau lokalisierbar), in der Mitte weniger Integrationstests, oben nur wenige End-to-End-Tests über die Oberfläche (langsam, wartungsintensiv, bei Fehlschlag schwer zu deuten). Das Gegenbild heißt Eistüte: kaum Unit-Tests, dafür Hunderte manuelle Klicktests. Das ist der Zustand, in dem jede Änderung zur Mutprobe wird.
2. Stub und Mock. Daniel hat geschrieben, dass Unit-Tests die Nachbarkomponenten durch Platzhalter ersetzen. Davon gibt es zwei wichtige Sorten:
- Ein Stub liefert nur feste Antworten, damit der Test überhaupt laufen kann – etwa ein Wechselkursdienst, der immer 1,10 zurückgibt.
- Ein Mock prüft zusätzlich, ob und wie er aufgerufen wurde – etwa ob beim Abschluss einer Bestellung genau eine Bestätigungsmail ausgelöst wurde.
Merksatz: Stub = Zustand prüfen, Mock = Verhalten prüfen.
3. Testgetriebene Entwicklung (TDD). Erst den Test schreiben, der fehlschlägt, dann gerade so viel Code, dass er grün wird, dann aufräumen – im Kreislauf „Red, Green, Refactor“. Das passt übrigens schön zu Tobis Hinweis, dass das erwartete Ergebnis vorher feststehen muss: Bei TDD ist das gar nicht anders möglich.