BDD - Test Driven Development

Wenn Sie sich eine Referenz zur verhaltensgesteuerten Entwicklung ansehen, werden Sie die Verwendung von Phrasen wie „BDD wird von TDD abgeleitet“, „BDD und TDD“ finden. Um zu wissen, wie BDD entstanden ist, warum es von TDD abgeleitet sein soll und was BDD und TDD sind, muss man TDD verstehen.

Warum testen?

Lassen Sie uns zunächst die Grundlagen des Testens erläutern. Mit dem Testen soll sichergestellt werden, dass das erstellte System wie erwartet funktioniert. Betrachten Sie das folgende Beispiel.

Aus Erfahrung haben wir daher gelernt, dass es kosteneffektiv wäre, einen Defekt bei seiner Einführung aufzudecken und sofort zu beheben. Daher müssen in jeder Entwicklungs- und Testphase Testfälle geschrieben werden. Dies haben uns unsere traditionellen Testpraktiken gelehrt, was oft als Test-Early bezeichnet wird.

Dieser Testansatz wird als Test-Last-Ansatz bezeichnet, da der Test nach Abschluss einer Phase durchgeführt wird.

Herausforderungen mit Test-Last-Ansatz

Der Test-Last-Ansatz wurde in den Softwareentwicklungsprojekten einige Zeit verfolgt. In der Realität wird bei diesem Ansatz, da das Testen warten muss, bis die bestimmte Phase abgeschlossen ist, häufig übersehen, weil -

Die Verzögerungen bei der Fertigstellung der Etappe.
Enge Zeitpläne.
Konzentrieren Sie sich auf pünktliche Lieferung und überspringen Sie Tests.

Darüber hinaus werden beim Test-Last-Ansatz häufig Unit-Tests übersprungen, die von den Entwicklern durchgeführt werden sollen. Die verschiedenen Gründe basieren auf der Denkweise der Entwickler -

Sie sind Entwickler und keine Tester.
Das Testen liegt in der Verantwortung der Tester.
Sie sind effizient in der Codierung und ihr Code würde keine Fehler aufweisen.

Dies führt zu -

Kompromisse bei der Qualität des gelieferten Produkts.
Die Verantwortung für die Qualität liegt nur bei Testern.
Hohe Kosten bei der Behebung der Mängel, Nachlieferung.
Unfähigkeit, Kundenzufriedenheit zu erreichen, was auch den Verlust des Wiederholungsgeschäfts bedeuten würde und somit die Glaubwürdigkeit beeinträchtigen würde.

Diese Faktoren erforderten einen Paradigmenwechsel, um sich auf das Testen zu konzentrieren. Das Ergebnis war der Test-First-Ansatz.

Test-First-Ansatz

Der Test-First-Ansatz ersetzt die Inside-Out-Methode (Code schreiben und dann testen) durch Outside-In (Test schreiben und dann Code schreiben).

Dieser Ansatz ist in die folgenden Softwareentwicklungsmethoden integriert (die auch agil sind):

eXtreme PProgrammierung (XP).
TEuropäische Sommerzeit Dgespalten DEntwicklung (TDD).

Bei diesen Methoden entwirft und schreibt der Entwickler die Komponententests für ein Codemodul, bevor er eine einzelne Zeile des Codemoduls schreibt. Der Entwickler erstellt dann das Codemodul mit dem Ziel, den Unit-Test zu bestehen. Daher verwenden diese Methoden Unit-Tests, um die Entwicklung voranzutreiben.

Der grundlegende Punkt zu beachten, dass das Ziel die Entwicklung auf der Grundlage von Tests ist.

Rot-Grün-Refaktor-Zyklus

Test Driven Development wird verwendet, um den Code zu entwickeln, der von Unit-Tests geleitet wird.

Step 1 - Betrachten Sie ein Codemodul, das geschrieben werden soll.

Step 2 - Schreiben Sie einen Test

Step 3 - Führen Sie den Test aus.

Der Test schlägt fehl, da der Code noch nicht geschrieben ist. Daher wird Schritt 2 normalerweise als Schreiben eines fehlgeschlagenen Tests bezeichnet.

Step 4 - Schreiben Sie den Mindestcode, der zum Bestehen des Tests möglich ist.

Step 5- Führen Sie alle Tests durch, um sicherzustellen, dass sie alle noch bestehen. Unit-Tests werden automatisiert, um diesen Schritt zu erleichtern.

Step 6 - Refactor.

Step 7 - Wiederholen Sie die Schritte 1 bis 6 für das nächste Codemodul.

Jeder Zyklus sollte sehr kurz sein und eine typische Stunde sollte viele Zyklen enthalten.

Dies ist im Volksmund auch als bekannt Red-Green-Refactor Zyklus, wo -

Red - Schreiben eines fehlgeschlagenen Tests.
Green - Schreiben von Code, um den Test zu bestehen.
Refactor - Entfernen Sie Duplikate und verbessern Sie den Code auf die akzeptablen Standards.

TDD-Prozessschritte

Die Schritte eines TDD-Prozesses sind unten dargestellt.

Vorteile von TDD

Die Vorteile oder Vorteile der testgetriebenen Entwicklung sind:

Der Entwickler muss zuerst verstehen, was das gewünschte Ergebnis sein soll und wie er es testen kann, bevor er den Code erstellt.
Der Code für eine Komponente wird erst beendet, wenn der Test bestanden und der Code überarbeitet wurde. Dies stellt das Testen und Refactoring sicher, bevor der Entwickler mit dem nächsten Test fortfährt.
Da die Suite von Unit-Tests nach jedem Refactoring ausgeführt wird, ist die Rückmeldung, dass jede Komponente noch funktioniert, konstant.
Die Unit-Tests dienen als lebende Dokumentation, die immer den Daten entspricht.
Wenn ein Fehler gefunden wird, erstellt der Entwickler einen Test, um diesen Fehler aufzudecken, und ändert dann den Code, sodass der Test erfolgreich ist und der Fehler behoben ist. Dies reduziert die Debugging-Zeit. Alle anderen Tests werden ebenfalls ausgeführt. Wenn sie bestanden werden, wird sichergestellt, dass die vorhandene Funktionalität nicht beeinträchtigt wird
Der Entwickler kann jederzeit Entwurfsentscheidungen treffen und umgestalten, und die Ausführung der Tests stellt sicher, dass das System noch funktioniert. Dies macht die Software wartbar.
Der Entwickler hat das Vertrauen, Änderungen vorzunehmen, da die Änderung durch Auswirkungen auf vorhandene Funktionen durch Ausführen der Tests aufgedeckt wird und die Fehler sofort behoben werden können.
Bei jedem aufeinanderfolgenden Testlauf werden auch alle vorherigen Fehlerbehebungen überprüft und die Wiederholung desselben Fehlers wird reduziert.
Da die meisten Tests während der Entwicklung selbst durchgeführt werden, werden die Tests vor der Auslieferung verkürzt.

Nachteile von TDD

Ausgangspunkt sind User Stories, die das Verhalten des Systems beschreiben. Daher stehen die Entwickler häufig vor folgenden Fragen:

Wann testen?
Was zu testen?
Woher wissen, ob eine Spezifikation erfüllt ist?
Liefert der Code Geschäftswert?

Missverständnisse über TDD

Die folgenden Missverständnisse bestehen in der Branche und müssen geklärt werden.

Missverständnis	Klärung
Bei TDD dreht sich alles um Testen und Testautomatisierung.	TDD ist eine Entwicklungsmethode, die den Test-First-Ansatz verwendet.
TDD beinhaltet kein Design.	TDD beinhaltet eine kritische Analyse und ein Design basierend auf den Anforderungen. Das Design entsteht während der Entwicklung.
TDD ist nur auf Einheitenebene.	TDD kann auf Integrations- und Systemebene verwendet werden.
TDD kann nicht von herkömmlichen Testprojekten verwendet werden.	TDD wurde bei Extreme Programming populär und wird in anderen agilen Methoden verwendet. Es kann jedoch auch in herkömmlichen Testprojekten verwendet werden.
TDD ist ein Werkzeug.	TDD ist eine Entwicklungsmethode und wird nach jedem neuen Unit-Test zur Automation Test Suite hinzugefügt, da alle Tests ausgeführt werden müssen, wenn ein neuer Code hinzugefügt oder vorhandener Code geändert wird, und auch nach jedem Refactoring. Daher erleichtern Testautomatisierungstools, die TDD unterstützen, diesen Prozess.
TDD bedeutet, den Entwicklern Akzeptanztests zu übergeben.	TDD bedeutet nicht, den Entwicklern Akzeptanztests zu übergeben.

Akzeptanz TDD

Acceptance Test Driven Development (ATDD) definiert Akzeptanzkriterien und Akzeptanztests während der Erstellung von User Stories zu Beginn der Entwicklung. ATDD konzentriert sich auf die Kommunikation und das gemeinsame Verständnis zwischen Kunden, Entwicklern und Testern.

Die wichtigsten Praktiken bei ATDD sind wie folgt:

Besprechen Sie reale Szenarien, um ein gemeinsames Verständnis der Domäne aufzubauen.
Verwenden Sie diese Szenarien, um zu Akzeptanzkriterien zu gelangen.
Akzeptieren Sie Abnahmetests.
Konzentrieren Sie die Entwicklung auf diese Tests.
Verwenden Sie die Tests als Live-Spezifikation, um Änderungen zu erleichtern.

Die Verwendung von ATDD bietet folgende Vorteile:

Die Anforderungen sind eindeutig und ohne funktionale Lücken.
Andere verstehen die Sonderfälle, die die Entwickler vorhersehen.
Die Abnahmetests leiten die Entwicklung.

TDD gegen BDD

Laut Dan North haben Programmierer normalerweise die folgenden Probleme, wenn sie testgetriebene Entwicklung durchführen:

Wo soll man anfangen
Was zu testen und was nicht zu testen
Wie viel auf einmal zu testen
Wie sollen ihre Tests genannt werden?
Wie man versteht, warum ein Test fehlschlägt

Die Lösung für all diese Probleme ist die verhaltensgesteuerte Entwicklung. Es hat sich aus den etablierten agilen Praktiken heraus entwickelt und soll sie für Teams zugänglicher und effektiver machen, die für die Bereitstellung agiler Software neu sind. Im Laufe der Zeit ist BDD gewachsen, um das Gesamtbild der agilen Analyse und der automatisierten Abnahmetests zu erfassen.

Die Haupt difference between TDD and BDD ist das -

TDD beschreibt, wie die Software funktioniert.
Auf der anderen Seite BDD -
- Beschreibt, wie der Endbenutzer die Software verwendet.
- Fördert die Zusammenarbeit und Kommunikation.
- Betont Beispiele für das Verhalten des Systems.
- Zielt auf die aus den Beispielen abgeleiteten ausführbaren Spezifikationen ab