Was ist TDD?
Im Kontext eines Unternehmens besteht der Zweck von Software darin, einen Mehrwert für dieses Unternehmen zu schaffen. Aus diesem Grund besteht eine der größten Herausforderungen bei allen Entwicklungsanstrengungen darin, Geschäftsanforderungen und -Ziele in die entsprechenden Systemanforderungen einzuordnen. Im Anschluss daran stellt sich die Frage, wie Sie Software schreiben, um diese Anforderungen zu erfüllen, und wie Sie mit zunehmendem Wachstum Ihres Projekts und seiner Codebasis sicherstellen, dass Ihre Software diese Anforderungen auch weiterhin erfülltTesten Sie Die Entwicklung.
Test-Driven Development, oder TDD, ist eine organisatorische Methodik zum Schreiben von Software durch das Schreiben von Tests, die diese Software beschreiben und anwenden. Im Kern besteht TDD aus einer Wiederholung von drei Schritten: Einen fehlgeschlagenen Test schreiben, ihn bestehen lassen, refaktorieren.
Der Gedanke ist, dass Sie mit einem Test beginnen, der eine Funktion für die Software-Funktion beschreibt, die gerade entwickelt wird. Die erstmalige Ausführung dieses Tests sollte zu einem Fehler führen, da der zu testende Code noch nicht geschrieben wurde. Der nächste Schritt besteht natürlich darin, die Funktion zu implementieren, mit dem Ziel, den ursprünglichen Test zu bestehen. Der dritte und wohl wichtigste Schritt des Lebenszyklus besteht darin, den Code dann umzufaktorieren.
Das Schreiben von Software ist nicht nur wegen ihrer intrinsischen Eigenschaften, sondern auch wegen ihrer dynamischen Natur eine Herausforderung. Geschäftliche Anforderungen können sich ständig ändern, und daher müssen sich die Softwareanforderungen anpassen können. Der Code, der heute geschrieben wird, wird den heutigen Bedürfnissen entsprechen, aber morgen oder in einem Monat von morgen wird sich etwas ändern, und infolgedessen ist der heutige Code möglicherweise nicht mehr der beste Weg, um ein bestimmtes Problem zu lösen. Durch Einführung eines Mechanismus zum Vergleich der Software Ist Eine Aufzeichnung der Software durchführen Sollte Wir haben jetzt ein leistungsfähiges Tool, mit dem wir unseren Code furchtlos auseinanderreißen, neu schreiben und anderweitig neu verdrahten können, um die heutigen Anforderungen zu erfüllen, denn wir können sicher sein, dass, solange alle unsere Tests bestehen, die Ausgabe des Systems gleich sein sollte.
Warum sollten wir TDD verwenden?
Eine 2014 von der Universität Helsinki durchgeführte Überprüfung ergab, dass TDD in vielen Fällen positive Auswirkungen in Bezug auf Fehler, Qualität, Komplexität und Wartbarkeit hatte, dass diese Verbesserungen jedoch auf Kosten verstärkter Entwicklungsbemühungen gehen können. Dies ist keine überraschende Schlussfolgerung, da das Schreiben zusätzlicher Tests zusätzliche Anstrengungen erfordert – aber was Studien dieser Art auslassen scheinen, ist der Hauptvorteil von TDD, nämlich Feedback.
Das Schließen der Feedback-Schleife bedeutet, die Zeit zu verkürzen, die erforderlich ist, um eine Änderung vorzunehmen und etwas zu lernen. Je schneller Sie dies tun können, desto agiler können Sie sein. Die meisten Kennzahlen zur Quantifizierung der Entwicklungsproduktivität beziehen sich auf Arbeitseinheiten im Zeitverlauf. Durch die Reduzierung der Zeit, die für das Erhalten von umsetzbarem Feedback benötigt wird, ermöglicht TDD eine effizientere Nutzung dieser wertvollen Ressource. Man sagt, Zeit sei Geld, daher ist der wirtschaftliche Nutzen hier selbstverständlich. Wenn Sie jemals gehört haben, dass jemand im Kontext des Softwareentwicklungszyklus eine „Linksverschiebung“ erwähnt hat, ist genau das, worauf sie sich beziehen.
Ein weiterer Vorteil einer Testsuite für Ihre Anwendung ist, dass Sie diese automatisieren können. Entwickler können diese Tests nicht nur im Rahmen des Entwicklungszyklus durchführen, sondern auch von anderen Systemen im Rahmen von Rauchtests oder einer CI/CD-Pipeline durchgeführt werden. Durch die Automatisierung der Schritte zur Bereitstellung von Code auf den Markt ermöglicht es eine schnellere Bereitstellung des Produkts als Ganzes, was wiederum das Feedback der Benutzer beschleunigt, das dann interpretiert und auf die nächste Iteration angewendet werden kann.
Die Synergieeffekte dieser beiden Punkte liegen auf der Hand: Mit einer Codebasis, die es Entwicklern ermöglicht, die Codebasis kontinuierlich an die Anforderungen des Unternehmens anzupassen, und der Fähigkeit für das Unternehmen, schnell Feedback von seinen Kunden einzuholen, ist das Ergebnis ein System, das es Teams ermöglicht, durch weniger Arbeit mehr Wert zu erzielen.
Das Beste aus TDD herausholen
Testgesteuerte Entwicklung ist nur einer von vielen verschiedenen Ansätzen zum Testen von Software. Der wichtige Teil ist, wie auch immer Sie sich für die Implementierung entscheiden, dass es Ihrem Unternehmen einen Mehrwert bietet. Wie jede andere Disziplin sollten Sie es frei nutzen, anpassen oder gar nicht nutzen können, und zwar ganz auf die Bedürfnisse Ihres Unternehmens. Wenn Sie sich aber dafür entscheiden, den TDD-Pfad zu gehen, wie der Prophet Clapton vorausgesagt hat: „Es ist in der Art, wie Sie ihn benutzen.“
Wie jedes andere Instrument hängt die Wirksamkeit und der Wert von TDD von seiner Implementierung ab. Zu oft werden in der Softwareentwicklung verschiedene Tools oder Techniken zu Sündenböcken gemacht, um die Misserfolge oder Mängel eines Projekts zu erklären, aber es ist ein armer Handwerker, der seine Werkzeuge beschuldigt. Konzentrieren wir uns also darauf, wie Sie das Beste aus TDD herausholen können.
Kulturelles Refactoring
Der letzte und wichtigste Schritt von TDD ist die Refaktorierung des Codes – aber damit TDD funktioniert, ist dies wahrscheinlich nicht der einzige Refactoring, der durchgeführt werden muss. Sollten Sie sich für eine Form der testgetriebenen Entwicklung entscheiden, ist es wichtig, dass sich auch die umgebende Kultur an diese Art der Entwicklungsphilosophie anpasst.
Im Fall von TDD ist der häufigste Fehler, dass der kontinuierliche Zyklus von Schreibtests, die sie bestehen, und dann das Refactoring nie tatsächlich abgeschlossen wird, sondern durch Überspringen des Refactoring-Schritts kurzgeschlossen wird. Meistens geht es nicht um TDD oder eine andere spezifische Technik, sondern um die Kultur, in der die Software entwickelt wird.
Anders als bei der Dokumentation scheint das Refactoring eines der ersten Dinge zu sein, die über Bord geworfen werden, wenn Fristen oder Budgets eng sind, denn schließlich muss jemand all diese Tests schreiben. Und so folgt, dass während der knackigen Zeit die Tests und die Dokumentation und alles andere, was nicht als geschäftskritisch angesehen wird, weggeworfen werden. Die Folge ist ein stetiger Rückgang der Gesamtqualität der Codebasis und an ihrer Stelle eine Anhäufung technischer Schulden.
Refactoring ist der Schritt des Prozesses, der darauf abzielt, Code, der einfach in eine Codebasis umgewandelt werden kann, die sauberer und wartungsfreundlicher ist. Es ist der Teil, der es den Entwicklern ermöglicht, einen Schritt zurückzugehen und Muster innerhalb des Gesamtsystems zu erkennen und fundiertere Entscheidungen darüber zu treffen, wie sie angepasst werden können, um vielseitiger zu sein oder neue Anti-Muster zu erkennen und Maßnahmen zu ergreifen, um sie zu mindern. Es kann sogar der Unterschied sein, ob man erkennt, wann es an der Zeit ist, die gesamte Architektur in diskrete Mikroservices aufzuteilen, oder ob man eine Vielzahl von potenziellen Verbesserungen erkennen kann. Ohne diesen Schritt können Sie Gelegenheiten für Introspektion und inkrementelle Verbesserungen verpassen, und letztendlich riskiert Ihre Codebasis eine allmähliche (oder nicht) Umwandlung in eine große Schlammkugel.
Um von den Vorteilen der Test-Driven Development zu profitieren, ist es wichtig, dass die Kultur den Prozess als Ganzes und sein Potenzial lange betrachtet und die Zeit in die Anwendung des kompletten Zyklus „Rot, Grün, Refaktor“ investiert, und nicht nur die zweckdienlichen Bits.
Glänzendes Neues Spielzeug
Wenn es um das Systemdesign als Ganzes geht, wird oft zu viel Zeit mit der Planung der Systemspezifikationen verbracht, ohne tatsächlich Code zu schreiben. Ein „Green Field“-Projekt kann spannend sein, da es das gesamte antizipierende Potenzial eines sauberen Blattes aufweist. Ingenieure und Architekten fallen gleichermaßen Opfer von Try-this-itis, wo sie sich für die Verwendung einer Technologie des „Flavor of the Month“ einsetzen, wobei sie jedes Warnsignal ignorieren, dass es nicht gut für dieses Projekt geeignet ist, sondern die Möglichkeit, etwas Neues oder cooles auszuprobieren. Nach ein paar Monaten erfüllt das Framework-du-jour nicht mehr die Anforderungen des Teams, die Qualität des Codes leidet und wir sind wieder zu dem Teil zurückgekehrt, in dem die Technologie zum Sündenbock für das schlechte Ergebnis des Projekts wird.
Am Ende des Tages ist es wichtig, dass die Technologie, Methodik oder das Framework, die zur Unterstützung von TDD verwendet werden, für das Team und für das Unternehmen funktioniert. Wenn Sie von Ihren Werkzeugen behindert werden, schaffen sie nicht nur keinen Mehrwert, sondern arbeiten auch aktiv gegen Sie. Prüfen Sie sorgfältig, welches Framework Sie verwenden möchten, und nehmen Sie sich die Zeit, genau zu verstehen, wie Sie es verwenden werden. Dieser Ansatz gilt für alle Konstruktionsentscheidungen, nicht nur für die Entscheidungen im Zusammenhang mit TDD!
Zusammenfassung
Kurz gesagt, die Idee von TDD besteht darin, einen Rahmen für das Sammeln von Feedback auf eine zweckmäßigere Weise bereitzustellen und nicht einfach nur eine Technik, um zu verhindern, dass Fehler in Ihrer Codebasis auftreten. Ganz gleich, für welchen Ansatz Sie sich entscheiden, der Schlüssel sollte darin bestehen, dass Ihr Unternehmen und seine Software schneller an sich ändernde Trends und Geschäftsanforderungen angepasst werden können. Denken Sie dabei daran, dass TDD und seine Kollegen nicht einfach nur etwas sind, das Sie Ihr Entwicklungsteam zur Implementierung auffordern und dann vergessen können. Um diese Techniken effektiv nutzen zu können, müssen Sie darauf achten, den Ansatz auf kultureller Ebene zu unterstützen und zu ermöglichen, bevor Sie sich mit Implementierungsdetails wie Frameworks und Tools befassen.
