Einführung

Testgetriebene Entwicklung ist eine effektive Methode, um gut getesteten und umgestaltbaren Code sicherzustellen. Die Grundidee besteht darin, dass Sie mit der Entwicklung beginnen, indem Sie Tests schreiben. Diese Tests dokumentieren die Erwartungen klar und bilden eine Grundlage für eine erfolgreiche Umsetzung. Wenn Sie es richtig machen, können Sie die erwartete Eingabe/Ausgabe einer Funktion klar definieren, bevor Sie Code schreiben. Dies hat einige unmittelbare Vorteile:

• Sie überlegen sich sorgfältig die Schnittstelle für die Interaktion mit Ihrem Code und entwerfen sie so, dass sie testbar ist
• Wenn Sie mit dem Schreiben von Code beginnen, wird Ihr Ablauf nicht durch manuelle Tests oder das Durchlaufen der Ausführungslogik zur Vorhersage des Ergebnisses unterbrochen. Stattdessen führen Sie einfach die Tests aus
• Das Bestehen einer Prüfung wird zu einem zufriedenstellenden Ziel. Die Unterteilung des Prozesses in eine Reihe klar definierter und erreichbarer Meilensteine ​​macht die Arbeit angenehmer
• Vermeiden Sie Faulheit und Selbstüberschätzung nach der Implementierung, die Sie daran hindern könnten, Ihren Code zu testen.

Da Sie nun von den Vorteilen überzeugt sind, können Sie mit der testgetriebenen Entwicklung (TDD) beginnen, indem Sie die folgenden Schritte ausführen:

1. Tests schreiben oder ändern
2. Überprüfen Sie, ob der Test fehlschlägt
3. Schreiben Sie die Mindestmenge an Code, damit die Tests erfolgreich sind

Diese Schritte werden in einem Zyklus ausgeführt, sodass Sie immer weitere Tests hinzufügen, um die aktuelle Implementierung in Frage zu stellen.

Der letzte Schritt, der das Schreiben der Mindestmenge an Code angibt, kann bei strikter Befolgung mühsam werden. Es ist wichtig zu verstehen, warum diese Regel existiert, bevor Sie entscheiden können, wann es angebracht ist, davon abzuweichen.

Einfaches Beispiel

Sie haben die Aufgabe, die Funktion Add(x, y int) int zu implementieren. Bevor Sie zur Implementierung springen und einfach x y zurückgeben, schreiben Sie den einfachsten Test: 1 1 == 2. Welche einfachste Implementierung würde dann den Test bestehen? Es ist nur Rückgabe 2. Jetzt bestehen Ihre Tests!

An diesem Punkt wird Ihnen klar, dass Sie weitere Tests benötigen, also erhöhen Sie das Tempo und fügen noch ein paar hinzu:

• 1 2 == 3
• 100 5 == 105

Jetzt schlagen Ihre Tests fehl, sodass Sie die Implementierung korrigieren müssen. Diesmal können Sie nicht einfach 3 oder 105 zurückgeben, Sie müssen also eine Lösung finden, die für alle Tests funktioniert. Dies führt zur Implementierung: return x y.

Während sich dies in dem trivialen Beispiel übermäßig langweilig anfühlt, hat die strikte Einhaltung dieser Methode dazu geführt, dass Sie mehrere Tests geschrieben haben, anstatt nur Ihrer Implementierung zu vertrauen. Natürlich hätte Ihre ursprüngliche Idee, x y zurückzugeben, funktioniert, aber es geht darum, sich neu anzueignen, sich auf Tests zu verlassen und nicht auf Ihr eigenes Verständnis des Codes. In der realen Welt sind Sie nicht der Einzige, der an diesem Code arbeitet, und werden unweigerlich Implementierungsdetails vergessen. Dieser Prozess zwingt Sie dazu, mehr Tests zu schreiben und sich mehr Möglichkeiten auszudenken, um die einfache Implementierung zu durchbrechen.

Mit der Zeit werden Sie Erfahrung sammeln und lernen, die Balance zu finden, die in den verschiedenen Szenarien, denen Sie begegnen, funktioniert. Sie kehren zur Implementierung der Funktionen mit voller Geschwindigkeit zurück und stellen fest, dass Sie weniger Fehler haben und wartbareren Code schreiben können.

Schritt-für-Schritt-TDD für eine HTTP-API

Kommen wir zu einem komplizierteren Beispiel mit TDD für eine HTTP-REST-API. Diese Schritt-für-Schritt-Anleitung verwendet mein Go-Framework babyapi, aber die Konzepte können überall angewendet werden.

babyapi verwendet Generika, um eine vollständige CRUD-API rund um Go-Strukturen zu erstellen, wodurch es sehr einfach ist, eine vollständige REST-API und Client-CLI zu erstellen. Darüber hinaus stellt das Babytest-Paket einige Tools zum Erstellen von End-to-End-API-Tabellentests bereit. Die Verwendung von TDD auf API-Ebene ermöglicht das vollständige Testen der HTTP- und Speicherebenen einer neuen API oder Funktion auf einmal.

Haftungsausschluss: Da Babyapi den Großteil der Implementierung übernimmt und auch zum Generieren von Test-Boilerplates verwendet wird, beginnen wir technisch gesehen nicht mit TDD. Wir werden jedoch sehen, wie vorteilhaft es ist, wenn wir unserer API Unterstützung für PATCH-Anfragen hinzufügen.

1. Erstellen Sie ein neues Go-Projekt
   

2. Erstellen Sie das erste main.go anhand des einfachen Beispiels von babyapi
   

3. Verwenden Sie die CLI, um ein Test-Boilerplate zu generieren
   

4. Implementieren Sie jeden Test, indem Sie die Platzhalter mit dem erwarteten JSON ausfüllen
   

5. Führen Sie die Tests durch und stellen Sie sicher, dass sie erfolgreich sind!

6. Da PUT idempotent ist, müssen alle Felder enthalten sein. Um dies zu vermeiden, möchten wir Unterstützung für das Umschalten zwischen „Abgeschlossen“ und „PATCH“-Anfragen hinzufügen. Wir beginnen mit dem Hinzufügen eines einfachen Tests, wie diese Funktion voraussichtlich aussehen wird
   

7. Dieser Test schlägt fehl, da Babyapi PATCH standardmäßig nicht unterstützt. Wir können das Problem beheben, indem wir einen Patch für die TODO-Struktur implementieren. Da wir unsere Funktion mit zwei Tests definiert haben, besteht unsere einfachste Implementierung nicht nur darin, Completed = true zu setzen, sondern wir müssen den Wert aus der Anfrage
   verwenden.

8. Jetzt können wir den „Abgeschlossen“-Status eines TODOs ändern, aber wir können PATCH immer noch nicht verwenden, um andere Felder zu ändern, wie in dieser neuen Reihe von Tests gezeigt
   

9. Patch aktualisieren, um die verbleibenden Felder festzulegen
   

10. Unsere Tests schlagen immer noch fehl, da wir das TODO immer mit den Anforderungsfeldern aktualisieren, auch wenn diese leer sind. Beheben Sie dieses Problem, indem Sie die Implementierung aktualisieren, um nach leeren Werten zu suchen
    

11. Der neue UpdateWithPatch-Test besteht, aber unsere vorherigen Tests schlagen fehl. Da wir „Completed“ in „*bool“ geändert haben, werden TODOs, die mit einem leeren Wert erstellt wurden, als null
    angezeigt.

12. Implementieren Sie Render für TODO, damit wir Null als falsch behandeln können
    

Die Implementierung der PATCH-Funktion mit testgetriebener Entwicklung führte zu einer robusten Reihe von Tests und einer gut implementierten Funktion. Da wir damit begonnen haben, die erwartete Ein- und Ausgabe einer PATCH-Anfrage in Tests zu definieren, war es leicht, die Probleme zu erkennen, die dadurch verursacht wurden, dass in der Anfrage nicht nach leeren Werten gesucht wurde. Außerdem konnten unsere bereits vorhandenen Tests vor Breaking Changes schützen, wenn der Typ „Completed“ in „*bool“ geändert wurde.

Abschluss

Testgetriebene Entwicklung ist ein effektiver Ansatz zur Erstellung vollständig getesteten und korrekten Codes. Indem wir mit den Tests im Hinterkopf beginnen, können wir sicherstellen, dass jeder Teil des Codes so konzipiert ist, dass er testbar ist, anstatt Tests zu einem nachträglichen Gedanken zu machen.

Wenn Sie bei der Einführung von TDD zögern, finden Sie hier ein paar Ideen für den Einstieg:

• Probieren Sie es in einfachen Szenarien aus, in denen die Eingabe/Ausgabe einer Funktion klar ist und die Implementierung nicht übermäßig kompliziert ist. Sie können einen robusten Tabellentest für die Vielfalt der Ein-/Ausgaben schreiben, die auftreten können. Eine klare Darstellung der verschiedenen Szenarien kann die Implementierung vereinfachen
• Wenn Sie einen neuen Fehler beheben, haben Sie bereits eine Lücke in Ihren Tests festgestellt. Schreiben Sie zunächst einen Test, der diesen Fehler überhaupt identifiziert hätte. Lassen Sie diesen Test dann bestehen, ohne vorhandene Tests zu unterbrechen.
• Ähnlich wie im Babyapi-Beispiel können Sie TDD für API-Tests auf hoher Ebene verwenden. Sobald Sie eine Definition der erwarteten Anfrage/Antwort haben, können Sie Ihren gewohnten Entwicklungsablauf für detailliertere Teile der Implementierung fortsetzen

Auch wenn TDD nicht gut zu Ihrer Art, Code zu schreiben, passt, ist es dennoch ein leistungsstarkes Werkzeug, das Sie immer dabei haben sollten. Ich ermutige Sie, sich zumindest etwas Zeit zu nehmen, um es auszuprobieren und zu sehen, wie es sich auf Ihren Entwicklungsprozess auswirkt.