Tach!

Noch etwas ergänzende Information zu Tests und Test-Driven-Design (TDD): Wenn man es gemäß der Philosophie macht, schreibt man sich zunächst für einen oder mehrere Anwendungsfälle einen oder mehrere Tests. Das zu testende Objekt (im allgemeinen Sinne, nicht nur OOP) existiert zu dem Zeitpunkt lediglich als Dummy. Das heißt, seine Schnittstellen sind gemäß der Planung ausformuliert, aber der Körper fehlt. Die Tests prüfen typische Situationen und müssen zunächst wegen der fehlenden Geschäftslogik fehlschlagen, auch als Nachweis dass beim Fehlschlagen der Test sich die rote Lampe anschalten kann. Nun fügt man seine Geschäftslogik hinzu und die Tests müssen grün werden. Wenn man ganz gut ist, hat man bereits jetzt die möglichen Grenzfälle und die Fälle, in denen der Testkandidat kein positives Ergebnis liefern kann, im Kopf und schreibt dafür entsprechende Tests. Damit ist der Schritt erstmal abgeschlossen.

Im weiteren Verlauf der Entwicklungstätigkeit stellt sich nun beispielsweise heraus, dass der Testkandidat geändert werden muss. Gründe können unter anderem sein, dass die Geschwindigkeit zu wünschen übrig lässt oder dass der Code ein Refactoring benötigt. Es geht grad nicht darum, dass die Funktionalität aufgrund geänderter Anforderungen geändert werden muss, also lediglich um eine Überarbeitung mit beizubehaltender Funktionalität. Die Tests, die man nun bereits hat, stellen sicher, dass nach außen hin der Testkandidat weiterhin auf dieselbe Art und Weise funktioniert. Bei Abweichungen würden sonst Tests fehlschlagen. Ohne TDD müsste man die Funktionalität zu Fuß prüfen und darf dabei keinen der Testfälle vergessen, um die gleiche Qualität sicherzustellen.

Natürlich kommt in das ganze Spiel auch noch der Faktor Mensch und das Tellerrandproblem. Nicht immer gelingt es demjenigen, der die Testbedingungen formulieren sollte (Vergangenheit, nicht Konjunktiv), alle möglichen Fälle zu bedenken. So stellt sich mitunter erst im Betrieb heraus, dass es unter bestimmten Umständen zu Fehlfunktionen kommt. Bei TDD schreibt man sich nun zunächst neue Tests für ebendiesen Fehler und korrigiert anschließend den Testkandidaten. Am Ende des Tages müssen alle Tests korrekt durchlaufen, und es ist damit sichergestellt, dass durch die Korrektur nicht an anderer Stelle etwas kaputtgemacht wurde, was man nicht bemerkt hat. Der Fehler stellt sich ja nicht selten erst viel später heraus, so dass man vom Projekt schon wieder viel vergessen hat und garantiert nicht mehr alle möglichen Testfälle im Kopf behalten hat, um sie erneut durchspielen zu können.

Der Aufwand beim TDD ist zunächst enorm, noch viel größer als der Unterschied zwischen Schön-Wetter-Programmierung und robuster Programmierung mit Reagieren auf Fehlerbedingungen. Das Ergebnis ist jedoch auch eine Qualität, die man jederzeit, vor allem nach jeder Änderung, vollständig nachprüfen/nachweisen kann - natürlich nun in Abhängigkeit von der Qualität der Tests. Nebenbei hat man nun auch eine Art Dokumentation. Die Testfälle dokumentieren, welche Ergebnisse unter welchen Umständen zu erwarten sind. Wenn man sich beim Benennen der Testfälle Mühe gibt, bekommt man sogar leicht lesbare Form hin. Einige Test-Frameworks unterstützen das sogar noch, so dass sich auch der Code nacher eher wie menschliche Sprache liest. Beispielsweise (angelehnt an Tests im AngularJs-Tutorial):

it('should result in 42 when doing things', function() {
  var result = testCandidate.doThings();
  expect(result).toBe(42);
});

Abschließend sei noch erwähnt, dass TDD auch nicht die Antwort auf alle Probleme ist. So testet man üblicherweise nicht gegen externe Systeme. Diese generell zu überwachen ist Aufgabe von Monitoring-Systeme. Eine Datenbankabfrage in der Entwicklungsumgebung zu testen hat auch wenig Aussagekraft auf die Produktivumgebung. Die Interaktion zwischen Systemen ist auch nicht mehr Aufgabe von Unittests sondern von Integrationstests. Externe Systeme mit Mock-ups (Attrappen) nachzustellen, ist nicht einfach und fehleranfällg, weil man das Verhalten exakt nachbilden müsste.

dedlfix.