Test Driven Development (TDD) – Was steckt wirklich dahinter?


Mehr als zwei Faktoren

Gegen den nächsten Test hat unser Code natürlich keine Chance. Er produziert aktuell höchstens zwei Faktoren und die 8 besteht aus drei.

Wer jetzt glaubt, wir müssten nun wirklich den richtigen Algorithmus entwickeln, wird leider enttäuscht. Wir folgen hier lediglich wieder dem Prinzip der Verallgemeinerung und machen aus einem „if“ eine „while“.

Wenn das alles war, dann kann unser Code doch gar nicht so hässlich gewesen sein. Es fühlte sich nur so an. Mal sehen, ob wir überhaupt noch mehr tun müssen, als zu verallgemeinern.

Schritt für Schritt

Unser Code hat nichts was eine 3 produzieren könnte, er kennt bisher nur die 2.

Spontan fällt uns natürlich diese Lösung ein:

Sie erfüllt alle Tests, hält sich aber nicht an das DRY-Prinzip (Don’t Repeat Yourself). Wir haben hier offensichtlich doppelten Code und bei der nächsten Primzahl (5) geht es wieder nicht weiter. Wir können hier aber sehr schön die Verallgemeinerung erkennen. Die korrekte Lösung ist somit:

Wir haben also die 2 zu einer Variable verallgemeinert und gehen nun solange mögliche Faktoren durch wie $n größer 1 ist.

Fertig

Wir sind an dieser Stelle jetzt fertig. Wir können keinen Test im Sinne der Aufgabenstellung mehr schreiben, der noch fehlschlagen würde.

Aufräumarbeiten

Das könnte der Zeitpunkt für einen Refactor sein. Die letzte if-Bedingung kann beispielsweise nicht mehr eintreten und ist daher überflüssig. Wer mag, kann auch noch auf for-Schleifen umsteigen und ein paar weitere Zeilen sparen. Ich genüge mich aber mit dieser Lösung.

Wir haben Tests. Refactoring ist also einfach. Solange die Tests weiterhin erfolgreich verlaufen, haben wir auch nichts kaputt gemacht.