In der heutigen schnelllebigen Softwareentwicklungsumgebung es ist üblich, die Worte Test-Driven Development (TDD) zu hören. Diskussionen über ihre Vor- und Nachteile sind in der Softwareentwickler-Community weit verbreitet.
Manche sagen, dass TDD eine „unrealistische, ineffektive Moralkampagne für Selbsthass und Beschämung“ ist, und andere, dass es „nur ein Tool ist, das uns hilft, mithilfe von Refactoring schneller zu entwerfen“. [2].
„Schlechte Programmierer haben alle Antworten. Gute Tester haben alle Fragen.“
— Gil Zilberfeld
Aber Test-Driven Development ist kein neues Kind in der Stadt.
Die früheste allgemein bekannte Erwähnung stammt aus dem Jahr 1957 in D.D. McCrackens „Digital Computer Programming: The First General Introduction in Book Form, Stressing Actual Work with Computers“. Obwohl TDD in den wenigen darauffolgenden Jahren nicht weit verbreitet war, IBM hat ein Projekt für die NASA durchgeführt in den 1960er Jahren, als Entwickler „frühe Komponententests in Mikroinkrementen schrieben.
An einem warmen Sommerabend 1989 entwickelte sich Kent Beck das erste bekannte TDD-Framework - SUnit - und probierte es auf Smalltalk aus. TDD wurde dann geboren oder, genauer gesagt, wiederentdeckt. Kurz darauf begannen Agile- und TDD-Bewegungen, Programmierer dazu zu ermutigen, automatisierte Komponententests zu schreiben, wodurch das Testen in die Entwicklungsdisziplin aufgenommen wurde.
Anfangs schien es, wie bei vielen neuen Dingen, nur „dem Tagesjob mehr Zeit zu geben“. Die meisten von uns waren sich der Vorteile solcher Praktiken nicht ganz bewusst. Sie standen TDD skeptisch und kritisch gegenüber, da es als ziemlich unnötiger Zeit- und Arbeitsaufwand angesehen wurde.
Aber bevor wir weitermachen, lassen Sie uns einen Schritt zurücktreten und darüber nachdenken: was ist testgetriebene Entwicklung?
Auf den Punkt gebracht, Bei TDD wird ein automatisierter Test geschrieben, bevor ein Feature geschrieben wird.
Nehmen wir als Beispiel an, Bob muss ein neues Feature für seine großartige neue Idee für soziale Netzwerke entwickeln. Bob schreibt zunächst einen automatisierten Test, und obwohl die Funktion nicht korrekt implementiert ist, schlägt der Test fehl (d. h. rote Ampel). Bob schreibt also die Mindestmenge an Code, damit der Test erfolgreich ist (d. h. grünes Licht).
Sobald er grünes Licht hat, bereinigt Bob den Code und stellt sicher, dass die Funktion immer noch korrekt implementiert ist, indem er die Tests ausführt (d. h. er überarbeitet den Code). Ohne Duplikate sind der Code und die automatisierten Tests für andere leicht zu verwalten.
Dieses Verfahren wird auch als „Rot/Grün/Refaktor-Mantra“ bezeichnet, wobei rot bedeutet, dass die Tests nicht bestanden wurden, und grün bedeutet, dass die Tests bestanden wurden. Robert Cecil Martin, einer der Anführer der Bewegung für agile Methoden (und vielen als Onkel Bob bekannt), erwähnte in „Clean Code“, dass das Schreiben von Tests vor dem Schreiben von Produktionscode nur die Spitze des Eisbergs ist.
„Die einzige Möglichkeit, die Frist einzuhalten — die einzige Möglichkeit, schnell voranzukommen — besteht darin, den Code jederzeit so sauber wie möglich zu halten.“
— Onkel Bob, Sauberer Code
Um die wahren Vorteile von TDD hervorzuheben, machen wir eine Übung.
Stellen wir uns vor, wir starten eine neue Softwareanwendung ohne Test-Driven Development. Wir werden eine App implementieren, mit der Benutzer ihren Blog verwalten können.
Beginnen wir mit der Implementierung unserer ersten Funktion: Ermöglichen Sie Benutzern, sich zu registrieren, um ihr Blog zu erstellen. Sobald der Code fertig ist, müssen wir ihn manuell testen, um festzustellen, ob alles reibungslos funktioniert.
Wenn wir mit der ersten Funktion zufrieden sind, können wir mit der Codierung von Funktion Nummer zwei beginnen: Benutzern das Hinzufügen von Blogbeiträgen ermöglichen. Und wenn der Code fertig ist, testen wir die zweite Funktion manuell, um zu sehen, ob sie richtig funktioniert. Sobald wir zufrieden sind, können wir zum nächsten Feature übergehen, oder?
Aber... woher wissen wir, dass der neue Code den Benutzerregistrierungsprozess nicht unterbrochen hat (erstes Feature)?
Wir können die erste Funktion manuell testen und sehen, ob sie noch funktioniert. Bedeutet das, dass wir jedes Mal, wenn wir eine neue Funktion hinzufügen, N+1-Tests manuell ausführen müssen?
Die Antwort lautet ja.
Das Ergebnis ist das es ist so unglaublich teuer, alle Funktionen bei jeder neuen Version manuell zu testen, dass Projekte ohne TDD sehr anfällig für Regressionen sind. In Bezug auf die Softwareentwicklung liegt eine Regression vor, wenn eine Funktion, die in einer früheren Version funktionierte, in einer späteren Version nicht mehr funktioniert hat.
Die Schlussfolgerung ist, dass Projekte, bei denen TDD angewendet wird, in der Regel weniger Fehler aufweisen als Projekte ohne automatisierte Tests. Automatisierte Tests sind jedoch nicht kostenlos.
Auf den ersten Blick kann die Entwicklung einer Funktion mit automatisierten Tests 20 bis 50% mehr kosten als ohne Tests. Mit zunehmender Komplexität der Software wird es jedoch immer schwieriger, jedes einzelne Feature manuell zu testen.
Nach der Implementierung einiger Funktionen zahlt es sich bereits aus, Zeit in das Schreiben automatisierter Tests zu investieren.
In der Softwareentwickler-Community ist es inzwischen allgemein anerkannt, dass Projekte mit automatisierten Tests weniger fehlerbehaftet sind als Projekte ohne automatisierte Tests.
Es ist auch allgemein anerkannt, dass sich der Aufwand beim Schreiben eines Tests auszahlt, indem verhindert wird, dass Fehler in die Produktionsumgebung gelangen. Weniger Bugs bedeuten ein besseres Produkt. Und das führt normalerweise zu glücklicheren Benutzern. Ganz zu schweigen von glücklicheren Entwicklern, die ihre Zeit damit verbringen können, ein besseres Produkt zu entwickeln, anstatt ständig Fehler zu beheben.
Aber wie viele Tests sind genug? Müssen wir automatisierte Tests für jedes einzelne Feature schreiben?
Die Antwort lautet: Es kommt darauf an.
In TDD gibt es keinen formellen Testplan, was es zu einem informellen Prozess macht. Daher ist der Prozentsatz des Codes, der getestet werden muss, eine große Debatte.
„'Wie testet man? ' ist eine Frage, die nicht allgemein beantwortet werden kann. 'Wann soll getestet werden? ' hat jedoch eine allgemeine Antwort: so früh und so oft wie möglich.“
— Bjarne Stroustrup, Die C++-Programmiersprache
Wir haben festgestellt, dass eine Testabdeckung von über 80% keine größeren Vorteile bringt. Bei der Anwendung der 80% -Regel traten so wenige Fehler auf, dass das Schreiben von noch mehr Tests nur sehr, sehr marginale Vorteile hatte.
Um es in die reale Welt umzusetzen, nehmen wir nur ein Beispiel.
Vor Kurzem waren wir bei einem Projekt für eine umfangreiche Plattform aufgrund des Zeitdrucks für einige Sprints gezwungen, die automatische Testabdeckung auf 60% des Codes zu reduzieren.
Als neue Funktionen mit geringerer Reichweite veröffentlicht wurden, begannen wir, mehr Regressionen zu bekommen. Nachdem wir zwei Sprints mit einer Codeabdeckung von 60% abgeschlossen hatten, beschlossen wir, einen ganzen Sprint zu verwenden, nur um Fehler zu beheben und die Testabdeckung wieder auf Kurs zu bringen.
Hätte die Deckung nicht abgenommen, hätten wir nur einen halben Sprint statt um einen ganzen Sprint verspätet. Das ist also eine ganze Woche, die wir hätten sparen können, indem wir unsere Testabdeckung von vornherein erhöht hätten.
Stellen Sie sich vor, wie sich jemand fühlt, wenn die Zeit damit verbracht wird, nur hinter sich selbst her zu fegen und keine größeren und besseren Dinge zu bauen.
Unsere Faustregel lautet, immer automatisierte Tests für die komplexesten Funktionen anzuwenden. Automatisierte Tests für einfache Funktionen entwickeln wir nur, wenn die Abdeckung ohne diese Funktionen unter 80% liegt. Das bedeutet, dass wir weniger Zeit mit der Behebung von Fehlern verbringen und dass weniger Probleme von Endbenutzern angesprochen werden.
Also, um es zusammenzufassen, bei Imaginary Cloud wir lieben TDD und 80% Codeabdeckung ist unsere magische Zahl.
Je komplexer die Funktion ist, desto höher steht sie auf unserer Testprioritätenliste.
Wir haben ein Expertenteam für Softwareentwicklung bei Imaginary Cloud. Wenn Sie der Meinung sind, dass Sie Hilfe bei Ihrem digitalen Projekt gebrauchen könnten, schreiben Sie uns hier!
Fanden Sie diesen Artikel hilfreich? Diese könnten dir auch gefallen!
CEO von Imaginary Cloud und Mitautor des Buches Product Design Process. Ich mag Essen, Wein und Krav Maga (nicht unbedingt in dieser Reihenfolge).
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
