Die wahren Gründe für eine testgetriebene Entwicklung

Warum wenden die Leute TDD an? Ich verrate Ihnen ein Geheimnis: Es geht nicht um die Tests. Erfahren Sie mehr über das eigentliche Ziel und die Werte, die sich unter der Oberfläche der testgetriebenen Entwicklung verbergen.

Was sind die wahren Gründe für die Durchführung von TDD?

Testgetriebene Entwicklung (TDD) ist ein kontroverses Thema unter Entwicklern. Nach vielen Jahren, in denen ich TDD täglich praktiziere, glaube ich, dass ein Teil des Grundes darin liegt, dass einige Leute die Gründe für TDD nicht ganz verstehen.

Lassen Sie uns zunächst das größte Missverständnis aus dem Weg räumen: Bei TDD geht es nicht ums Testen. Es ist ein Mittel, um die Entwicklung voranzutreiben.

Das Ziel, so Test-Driven Development: By Example, ist einfach und doch mächtig:

Sauberer Code, der funktioniert

Ich liebe diese kurze Erklärung, und wenn es etwas gibt, das Sie aus diesem Beitrag mitnehmen, dann sollte es das sein. Die spezifischen Gründe für die Durchführung von TDD lassen sich jedoch am besten mit den Werten von Extreme Programming beschreiben. Diese sind:

• Rückmeldung
• Einfachheit
• Courage
• Kommunikation
• Respekt

TDD und die Werte von XP

TDD bietet viele Vorteile, aber ich bevorzuge eine andere Perspektive, die ein wenig tiefer geht. Meiner Meinung nach beschreibt Extreme Programming (XP) die Gründe für die Anwendung von TDD am besten.

Kent Beck hat in Extreme Programming Explained (ein Buch , das ich sehr empfehle) fünf Werte definiert, die die Grundlage für alles bilden, was dazugehört. Wie Sie sehen werden, baut auch TDD auf dieser Grundlage auf.

Doch zunächst ein paar Worte dazu, warum das alles überhaupt wichtig ist.

Warum sind Werte überhaupt wichtig?

Treiben Sie in irgendeiner Form Sport? Wenn ja, machen Sie wahrscheinlich vor und nach Ihren Anstrengungen einige Dehnübungen.

Aber warum dehnen Sie sich? Wahrscheinlich, weil Sie wissen, dass es Verletzungen vorbeugt und die Flexibilität erhöht. Ohne dieses Wissen erscheint Dehnen wie eine Verschwendung von Zeit und Mühe.

Es sind die einer Praxis zugrunde liegenden Werte, die ihr Bedeutung verleihen.

Um noch einmal auf TDD zurückzukommen: TDD ist unter den Entwicklern sehr umstritten. Softwareingenieure lieben oder hassen es, und ich vermute, dass einige von ihnen den tatsächlichen Wert von TDD nicht kennen und es daher als Zeit- und Arbeitsverschwendung ansehen. Lassen Sie mich beleuchten, warum TDD für Softwareentwickler äußerst wertvoll ist.

Verbessern Sie das Feedback durch den Einsatz von TDD

Erstens ist TDD eine der besten Möglichkeiten, um Feedback zu erhalten. Feedback zu was? Zu jedem einzelnen dieser Attribute:

• Korrektheit. Einfach ausgedrückt: Tut der Code das, was Sie wollen? Das entscheidende Unterscheidungsmerkmal ist, dass Sie mit TDD diese Informationen erhalten, während Sie noch das Problem kodieren. Sie brauchen keine Druckanweisungen oder Compiler in Ihrem Kopf, um herauszufinden, was der Code tut.
• Qualität. Eine Superkraft von TDD. Es zwingt Sie dazu, testbaren Code zu schreiben, d.h. lose gekoppelten und hochgradig kohärenten Code, was bedeutet, dass Ihr Code eine höhere Qualität hat. Wenn das Testen schwierig wird, ist das ein deutliches Zeichen dafür, dass Ihr Design verbessert werden könnte. TDD ist also ein effektiver Weg, um Feedback über die interne Qualität Ihres Codes zu erhalten.
• Fortschritt. Da Sie mit der Spezifikation des Verhaltens als fehlgeschlagener Test beginnen, wissen Sie genau, wann Sie fertig sind: sobald der Test grün ist. Wenn Sie dies mit akzeptanztestgetriebener Entwicklung oder verhaltensgetriebener Entwicklung kombinieren, wird das Feedback auf die Funktionsebene ausgeweitet.

TDD setzt Tests im Wesentlichen dazu ein, Feedback zu erzeugen. Wie ein Kompass zeigt er Ihnen ständig, ob Sie in die richtige Richtung gehen.

Vereinfachung mit TDD ❤️

Zweitens ist die testgetriebene Entwicklung eine großartige Möglichkeit, einfacheren Code zu schreiben. Einfachheit ist in der Programmierung schwer zu erreichen, aber sie ist ebenso wichtig. Sie hilft, die Komplexität zu beherrschen. Die Definition von Einfachheit, die mir am besten gefällt, stammt aus dem agilen Manifest:

Einfachheit - die Kunst, die Menge der nicht erledigten Arbeit zu maximieren - ist entscheidend.

Aber wie erreicht TDD diese magische Wirkung?

Erstens zwingt es Sie dazu, das Verhalten, das Sie benötigen, im Voraus eindeutig zu formulieren. Sie sollten am Ende genau den Code schreiben, den Sie brauchen, nach dem Prinzip"You Aren't Gonna Need It". Ein erfahrener TDD-Anwender möchte so schnell wie möglich von Rot auf Grün wechseln, und Einfachheit ist ein todsicherer Weg, dies zu erreichen.

Außerdem ist der letzte Schritt im tdd-Zyklus das Refactoring. Dieser kontinuierliche Refactoring-Zyklus führt zu einem besser lesbaren und einfacheren Code.

Mutig werden durch die Anwendung von TDD

Drittens erhalten Sie durch TDD eine gesunde Portion Mut. Mut scheint ein seltsamer Wert zu sein, den man mit TDD in Verbindung bringt, aber es ist der Wert, der in Test-Driven Development: by Example die meiste Aufmerksamkeit erhält. In dem Buch beschreibt Kent Mut als "Umgang mit Angst" und erklärt, wie TDD ein effektives Mittel dafür ist.

Was bedeutet Angst?

Haben Sie schon einmal unverständlichen Code ändern müssen? Wie wäre es mit Code, dem (gute) Tests fehlen? Das Gefühl, das Sie dabei hatten, war wahrscheinlich Angst. Sie hatten Angst, dass Sie den Code kaputt machen könnten. TDD sollte zu einer Codebasis führen, in der Sie diese Art von Angst nie wieder spüren müssen, weil Sie sich auf einen soliden Satz von Tests verlassen können. Diese geben Ihnen auf Knopfdruck Gewissheit, Mut auf Abruf.

TDD hilft Ihnen auch dabei, mit der Angst umzugehen, wenn Sie unsicher sind, wie Sie weitermachen sollen. Manchmal wissen Sie nicht, wie Sie ein Problem lösen sollen, und die Angst wird ihr hässliches Haupt erheben. Angst macht das Lösen von Problemen schwieriger. TDD ermöglicht es Ihnen, einen Gang zurückzuschalten und das Problem in kleinen Schritten zu lösen. Wenn Sie diese kleinen Schritte machen, können Sie die Angst überwinden und anfangen, Fortschritte zu machen.

Die Auswirkungen von TDD auf die Kommunikation ️

Kommunikation ist der vierte überzeugende Vorteil von TDD. Ein Ergebnis von TDD ist ein solider Satz von Tests. Wenn sie korrekt ausgeführt werden, vermitteln gut geschriebene Tests den Lesern das Verhalten des Systems.

Tests dokumentieren effektiv die Absicht des Codes und sind meine erste Anlaufstelle, um unbekannten Code zu verstehen. Stellen Sie sich vor, wie es wäre, wenn Ihre gesamte Codebasis über Tests verfügen würde, die erklären, was der Code unter bestimmten Bedingungen tut. Wäre das nicht großartig?

Wenn ich also Code in TDD-Manier schreibe, behalte ich immer den zukünftigen Leser des Codes und der Tests im Hinterkopf. Sie sollten sich in den Leser einfühlen. Mein Ziel ist es, zu verhindern, dass diese Person sich den Kopf zerbricht, und mit Tests kann ich dieses Ziel erreichen.

TDD zu machen zeigt Respekt

Und schließlich ist die Anwendung von TDD ein Zeichen von Respekt. Indem Sie TDD anwenden, zeigen Sie Respekt vor Ihrem:

• andere Teammitglieder
• Interessengruppen
• Benutzer

Und warum? Denken Sie an das Ziel von TDD zurück: sauberer Code, der funktioniert.

Für Ihre Teammitglieder bedeutet dies wartbaren, gut dokumentierten Code, mit dem es Spaß macht, zu arbeiten. Sie respektieren Ihre Stakeholder, da Sie gerade genug Code schreiben, um das Ergebnis zu erzielen, an dem sie interessiert sind. Außerdem können Sie so ein nachhaltiges Tempo bei der Bereitstellung von Funktionen beibehalten, indem Sie die technischen Schulden unter Kontrolle halten. Und schließlich kommen Ihre Benutzer in den Genuss eines stabilen, gut durchdachten Produkts mit weniger Fehlern.

"Aber ich bekomme diese Effekte auch mit Test-After" ☝️

Kritiker könnten diese Effekte betrachten und sagen, dass sie diese Effekte auch bei regelmäßigen, nachträglichen Tests erhalten. Diesen Leuten sage ich: Sie haben Recht... und Unrecht!

Sie werden einige dieser Vorteile erleben, aber nur bis zu einem gewissen Grad. Der entscheidende Unterschied zwischen TDD und dem Testen nach dem Testen ist, dass TDD den Moment, in dem diese Vorteile auftreten, nach vorne zieht. Er wird Teil des Weges zu Ihrer Lösung.

Beim Testen nach dem Testen codieren Sie die Lösung, dann folgt ein Test und erst dann beginnen Sie, Feedback zu generieren. Mit TDD hingegen können Sie die Vorteile bereits ab der ersten Zeile des Produktionscodes nutzen und sie bei jedem Schritt weiter erfahren.

Dieses Thema verdient jedoch einen eigenen Beitrag, also bleiben Sie dran!

Zusammenfassung

Testgetriebene Entwicklung ist eine effektive Programmierpraxis, die zu einfachem, gut durchdachtem Code führt. Aber wenn man sie anwendet, ohne die zugrunde liegenden Werte zu verstehen, ist sie eine leere Hülle. Sie machen TDD nicht um des TDD willen.

TDD folgt den übergreifenden Werten von XP. Wenn es richtig angewendet wird, können Sie erwarten, dass es die Kommunikation verbessert, Ihren Code vereinfacht, das Feedback erhöht, Ängste abbaut und allen Beteiligten Respekt entgegenbringt. Hört sich das nicht toll an?

Führen Sie TDD durch? Welche Auswirkungen von TDD haben Sie überrascht? Teilen Sie uns Ihre Gedanken im Kommentarbereich mit.

Weitere Lektüre

• Extreme Programmierung erklärt
• Testgetriebene Entwicklung: Am Beispiel
• Wachsende objektorientierte Software, geleitet von Tests