Test-Drive-Entwicklungsansatz für die agile Softwareentwicklung

Heute spricht man oft von agiler Entwicklung.

Was ist agile Entwicklung?

Agile Entwicklung  ist eine Softwareentwicklungsfunktion, die auf sich schnell ändernde Anforderungen reagiert. Ihre spezifischen Namen, Konzepte, Prozesse und Terminologie variieren. Im Vergleich zu „ nicht agil “ betonen sie die enge Zusammenarbeit zwischen Programmiererteams und Geschäftsexperten, persönliche Kommunikation (wird als effektiver angesehen als schriftliche Dokumentation) und liefern häufig neue Softwareversionen, kleine und  selbstorganisierte Teams  für kleine und das Schreiben wertvoller Funktionen sowie Ansätze zur Teamorganisation, die sich an sich ändernde Bedürfnisse anpassen, mit einem stärkeren Fokus auf die Rolle der Menschen in der Softwareentwicklung.

Es gibt jedoch mehrere ähnliche Versionen der agilen TDD-Entwicklungsmethoden, wie z. B. TDD: BDD, DDD und ATDD. Lassen Sie mich diese Methoden kurz vorstellen, bevor ich TDD im Detail vorstelle:

TDD: Testgetriebene Entwicklung

Test Driven Development  (TDD) ist ein Softwareentwicklungsprozess, der darauf beruht, Softwareanforderungen in Testfälle umzuwandeln, bevor die Software vollständig entwickelt ist, und die gesamte Softwareentwicklung zu verfolgen, indem Software wiederholt für alle Testfälle getestet wird. Dies ist das Gegenteil davon, zuerst Software zu entwickeln und dann Testfälle zu erstellen. Einige beliebte Modelle unterstützen TDD sehr gut, wie MVC und  MVP .

BDD: Verhaltensgesteuerte Entwicklung (Verhaltensgesteuerte Entwicklung)

Behavior Driven Development (BDD) ist ebenfalls ein agiler Softwareentwicklungsprozess. Es fördert die Zusammenarbeit zwischen Entwicklern, Qualitätsprüfern und Kundenvertretern in Softwareprojekten. Es ermutigt Teams, Gespräche und konkrete Beispiele zu nutzen, um ein gemeinsames Verständnis darüber zu formulieren, wie die Anwendung funktionieren sollte. Es stammt aus der testgetriebenen Entwicklung (TDD).

ATDD: Abnahmetestgetriebene Entwicklung

Um die Realisierung von funktionalem Code durch Unit-Testfälle zu fördern, muss das Team erwartete Qualitätsstandards und Akzeptanzregeln definieren und die TDD-Praxis der Entwickler und die Leistung der Tester durch einen klaren und konsistenten Akzeptanztestplan (einschließlich einer Reihe von Test Szenarien). Für Entwickler betont es, wie man das System implementiert und wie man es testet.

DDD: Design des Domänenlaufwerks

DDD bezeichnet Domain Driven Design, also domänengetriebene Entwicklung. DDD baut tatsächlich auf dieser Grundlage auf, weil es sich auf das Service Layer Design konzentriert, sich auf die Geschäftsimplementierung konzentriert, Analytik und Design kombiniert und nicht mehr in einem geteilten Zustand hält, um Kundenanforderungen korrekt und umfassend umzusetzen und ein Geschäftsmodell aufzubauen Skalierbarkeit.

TDD-Implementierungsplan

Durch Tests soll die gesamte Entwicklung gefördert werden, aber testgetriebene Entwicklung ist nicht nur eine einfache Testarbeit, sondern ein Prozess der quantifizierenden Anforderungsanalyse, des Designs und der Qualitätskontrolle.

Entwicklungsprinzipien

Schreiben Sie zuerst den Testcode und dann den Code für die Funktion.

1. Schreiben Sie Testcode gemäß dem Anforderungsdokument, um die Funktion nicht zu realisieren;
2. Ich möchte nicht mit einem Bissen fett sein. Beim Testen großer Funktionsblöcke sollten Sie diese zum Testen zuerst in kleinere Funktionsblöcke aufteilen;
3. Denken Sie daran, keinen Code zu schreiben, um die Funktion zu vervollständigen, verwenden Sie den einfachstmöglichen Code, um die Funktion zu implementieren.
4. Wenn die Anforderungen getestet werden können, schreiben Sie Testcode und geben Sie diejenigen auf, die nicht getestet werden können oder der Meinung sind, dass sie nicht getestet werden müssen;
5. Bevor Sie einen Funktionscode ändern/hinzufügen, müssen Sie zuerst überlegen, ob Sie Testfälle ändern/hinzufügen möchten;
6. Funktions-/Testcode, unangemessene Struktur, doppelter Code usw., refaktorisieren Sie rechtzeitig, nachdem der Test bestanden wurde.

TDD-Entwicklungsprozess

1. Analysieren und bestimmen Sie ein Zieltestszenario;
2. Fügen Sie einen Einheitentest hinzu, um die Eingabe und Ausgabe des Testszenarios zu überprüfen;
3. Führen Sie den Test durch und erhalten Sie das fehlgeschlagene Testergebnis;
4. Schreiben Sie den einfachsten Funktionscode, um den Test zu bestehen;
5. Führen Sie den Test erneut aus und prüfen Sie, ob der Test erfolgreich ist.
6. Code-Refactoring durchführen, einschließlich Funktionscode und Unit-Test-Code;
7. Wiederholen Sie die obigen Schritte, bis die Entwicklung abgeschlossen ist.

Vorteile von TDD

1. Reduzieren Sie die Belastung für Entwickler . Konzentrieren wir uns durch einen klaren Prozess jeweils nur auf einen Punkt, und die Last des Denkens ist geringer.
2. Das Schutznetz . Die Abdeckung vollständiger Unit-Tests bietet ein Schutznetz für den Produktcode, wodurch es einfach wird, geänderten Anforderungen gerecht zu werden oder das Code-Design zu verbessern. Wenn Ihre Projektanforderungen also stabil sind, sofort erledigt werden und keine nachträglichen Änderungen vorgenommen werden, sind die Vorteile von TDD geringer.
3. Anforderungen vorab klären . Das Schreiben von Tests kann uns dabei helfen, über die Anforderungen nachzudenken und die Details der Anforderungen im Voraus zu klären, anstatt unklare Anforderungen erst nach der Hälfte des Codes zu entdecken.
4. Schnelle Rückmeldung . Viele Leute sagen, dass sich mein Codevolumen erhöht, wenn TDD verwendet wird, sodass die Entwicklungseffizienz abnimmt. Wenn Sie jedoch keine Komponententests haben, müssen Sie sie manuell testen, Sie verbringen viel Zeit damit, Daten vorzubereiten, Apps zu starten, Schnittstellen zu ändern usw., und das Feedback ist langsam. Um genau zu sein, schnelles Feedback ist ein Vorteil von Unit-Tests.