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


Weiter mit den Primfaktoren

Ich erwähne ab hier nur noch die neuen Prüfungen (Assertions). Die alten bleiben aber immer bestehen.

Hier gilt es jetzt das große Ganze im Hinterkopf zu haben. Wir wollen schließlich einen Algorithmus für alle Zahlen schreiben und nicht nur für die, die wir testen werden. Jetzt also nur eine weitere if-Bedingung für 3 einzuführen würde zwar den Test erfüllen, uns aber dem Ziel nicht näher bringen.

Wichtig ist: Wir kopieren keinen Code, sondern wir verändern bestehenden Code vom Spezifischen zum Allgemeinen.

Heißt konkret, dass wir von der spezifischen „2“ zum allgemeinen „$n“ wechseln. Diesem Prinzip werden wir im weiteren Verlauf immer wieder begegnen.

Nach drei kommt vier

Der nächste Test ist klar. Er bringt aber eine neue Ebene in den Algorithmus. Wir haben das erste mal mehr als einen Faktor.

Nochmal: Wir müssen den Code verallgemeinern. Gleichzeit dürfen wir aber auch nur die einfachste Möglichkeit, den Test zu erfüllen, programmieren.

Das sieht also dann so aus:

Das erfüllt den Testfall für 4. Leider fällt uns jetzt aber der Testfall für 2 auf die Füße. Das ist auch der Grund, warum alle Testfälle weitergeführt werden. Wir benötigen also noch ein „if“.

Das sieht unglaublich hässlich aus, aber es erfüllt alle bisher definierten Bedingungen, ohne dass wir „Duplicated-Code“ haben.

Euch dürfte aufgefallen sein, dass wir zweimal die selbe Prüfung ($n > 1) durchführen. An deren Stelle könnte später eine Schleife treten, was auch die Verallgemeinerung darstellt.

What just happened?

Als nächstes kommt natürlich die 5.

Cool, nichts zu tun!

Wer hätte das gedacht!

Und noch einer. Obwohl wir also der Meinung sind hässlichen Code produziert zu haben, ist er schon ziemlich gut. Wir sind vermutlich gar nicht so weit weg vom „richtigen“ Algorithmus. Das könnte für einige der erste Aha-Moment gewesen sein.

Komplizierte Tests