Bei TDD geht es nicht ums Testen

Testgetriebene Entwicklung (TDD) gibt es schon seit mehr als 20 Jahren. Fast alle Größen der Softwarebranche betonen, dass es sich dabei um eine wichtige und wertvolle Methode handelt. Leider wird sie von vielen Entwicklern in der Praxis immer noch nicht angewandt.

Viele Menschen denken bei TDD an eine Testmethode, weil es so heißt. Es gibt einige negative Gefühle gegenüber dem Schreiben von Tests. Sie sehen Testen vielleicht als etwas Langweiliges an, das Sie haben zu tun, um zu beweisen, dass der von Ihnen geschriebene Code funktioniert. Sie schreiben einen Test, sehen, wie er beim ersten Durchlauf grün wird und freuen sich, wenn Sie eine Codeabdeckung von über 80% erreicht haben. Vielleicht entwickeln Sie gerne, indem Sie den Code ab und zu ausführen oder debuggen. Sobald Sie sehen, dass Ihr Code funktioniert, kommt Ihnen das Testen ein wenig sinnlos vor. Oder vielleicht haben Sie einen Tester in Ihrem Team, so dass die Tests, die Sie schreiben, noch überflüssiger erscheinen.

Dies alles führt zu negativen Gefühlen beim Schreiben von Tests. Das Ergebnis scheint offensichtlich. Wenn Sie Tests nicht mögen, warum sollten Sie sich dann mit TDD beschäftigen?

Es geht nicht um Tests, sondern um Design

Für mich ist der Grund einfach. Bei TDD geht es überhaupt nicht ums Testen. Bei TDD geht es um Design und frühes Feedback. Wenn wir TDD praktizieren, dann Code schreiben (in einem Test), um die Implementierung zu steuern.

Um das zu tun, müssen wir sofort anfangen, über das Design nachzudenken. Welche Abhängigkeiten hat mein Code? Werde ich Daten über eine API oder ein Repository abrufen müssen? Sollte das so sein? Was ist mit der Sprache? Wie sollte ich diese Klasse benennen? Welchen Namen sollte ich dieser Methode geben?

TDD ermöglicht es uns, uns auf diese Fragen zu konzentrieren, indem wir uns in kleinen Schritten einer funktionierenden Lösung nähern. Darauf werde ich im folgenden Abschnitt zurückkommen.

Indem wir über das Design nachdenken, bevor die eigentliche Implementierung geschrieben wurde, treffen wir bereits Entscheidungen über den wichtigsten Teil unseres Codes, das Modell, und haben die Möglichkeit, uns zunächst auf das große Ganze zu konzentrieren, anstatt uns sofort auf die Details zu konzentrieren. Diese Perspektive wird bei einem Test-nach-Ansatz oft nicht berücksichtigt.

Und da wir das brandneue Modell im Test selbst verwenden, erhalten wir Feedback, bevor überhaupt etwas implementiert wurde. Unser Test wirkt wie eine leere Leinwand, auf die wir die groben Umrisse unseres Modells malen. Dieser Blick von außen auf Ihren Code in einem so frühen Stadium ist sehr hilfreich, um festzustellen, ob Sie auf dem richtigen Weg sind. Da es noch keinen funktionierenden Code gibt, ist auch die Kopplung in diesem Stadium gering. Das macht es sehr einfach, verschiedene Wege auszuprobieren - wenn Sie sich trauen, das zu tun.

Inkrementelles Design und schnelles Feedback

Ein weiterer Aspekt, der uns hilft, ist, in kleinen Schritten vorzugehen, indem wir jeweils nur einen einzigen Aspekt des Codes spezifizieren. Das bedeutet, dass wir einen einzigen Test schreiben, bevor wir uns an die Implementierung machen. Indem wir kleine Schritte machen, stellen wir sicher, dass jeder Schritt so einfach und kurz wie möglich ist. Was stellen Sie sich leichter vor, 500 kg in einem Zug zu heben oder 50 Wiederholungen von 10 kg zu machen?

Jedes Mal, wenn wir den ared-green-refactor-Zyklus abschließen fühlen wir uns belohnt. Weil wir kleine Schritte machen, fühlen wir uns sehr oft belohnt. Und weil das Refactoring Teil des Zyklus ist, machen wir es oft und halten die Refactors jedes Mal klein und einfach. Dieses ständige Refactoring von Code und Tests verbessert die Qualität unseres Codes immens.

Wenn Sie früh und oft Feedback erhalten, können Sie wirklich schneller vorankommen. Ihre Fehler sind kleiner und haben weniger Auswirkungen. Vergleichen Sie das mit der Bildrate bei Spielen. Mehr Bilder pro Sekunde sind ein großer Vorteil!

Lebendige Spezifikation

Danach ist der resultierende Test wie eine Code-First-Spezifikation dessen, was die Implementierung tun muss. Dieses lebende Code-Artefakt unseres inkrementellen Designs ist für jeden, der nach Ihnen an Ihrem Code arbeitet, wahnsinnig hilfreich. Sie haben jetzt eine Spielwiese, auf der sie den Code erforschen können. Wenn sie sich nicht sicher sind, wie sich eine Einheit in bestimmten Fällen verhält, können sie die Spezifikation einfach um einen neuen Fall ergänzen. Sie können auch leichter auf dem aufbauen, was Sie gemacht haben. Sie können die Spezifikation so umschreiben oder ergänzen, dass sie zum neuen Anwendungsfall passt, und dann die Implementierung ändern.

Wenn sie einen Fehler finden, können sie schnell überprüfen, wie sich die Einheit verhält, wenn sie mit dem fehlerhaften Fall konfrontiert wird. Danach ist es nur noch ein kleiner Schritt, um festzulegen, wie die Einheit sollte verhalten und die Korrektur mit Zuversicht implementieren. Da Ihr Test immer ausführbar bleiben muss, damit er grün bleibt, können Sie sicher sein, dass er immer auf dem neuesten Stand ist. Der Test wird fehlschlagen, wenn die Implementierung gegen die Spezifikation verstößt. Textbasierte Dokumentation hat diesen Vorteil nicht und ist in dem Moment veraltet, in dem sie geschrieben wird.

Der wahre Wert

Wie Sie gelesen haben, geht es bei TDD nicht um Testen im klassischen Sinne. TDD ist eine Gewohnheit, bei der Sie Code mit Code entwerfen, und das wird Ihnen helfen:

• think about your models first. 
• use short cycles to give you feedback more often.
• enables you to get a different perspective on your code.
• see your tests as ”living specifications” rather than after-the-fact tests. 

Außerdem ist es auch eine Menge Spaß, dank der kurzen Zyklen von Fehlschlägen, Erfolgen und Überarbeitungen. Es bringt Sie dazu, Ihre Tests auf eine ganz andere Weise zu betrachten. Es braucht einige Zeit und echte Anstrengungen, um TDD richtig anzuwenden, aber es ist eine der wertvollsten Entwicklungsgewohnheiten, die Sie sich aneignen können.