it-swarm.com.de

Wie verwende ich Unit-Tests bei Verwendung von BDD?

Ich versuche BDD zu verstehen. Ich habe einige Artikel gelesen und wie ich verstanden habe, ist BDD "der nächste Schritt" von TDD. Ich sage das, weil ich finde, dass beide sehr ähnlich sind und wie ich in diesem Artikel lesen konnte, BDD als Verbesserung von TDD geboren wurde. Großartig, ich mag die Idee wirklich.

Es gibt einen praktischen Punkt, den ich nicht verstehe, dachte ich: Es gibt eine .feature-Datei, in die der BA das gesamte erwartete Verhalten des Systems schreibt. Als BA hat er keine Ahnung, wie das System aufgebaut ist, also werden wir so etwas schreiben:

+ Szenario 1: Konto ist gutgeschrieben +

Vorausgesetzt, das Konto ist gutgeschrieben

Und die Karte ist gültig

Und der Spender enthält Bargeld

Wenn der Kunde Bargeld anfordert

Stellen Sie dann sicher, dass das Konto belastet wird, und stellen Sie sicher, dass Bargeld ausgegeben wird

Und stellen Sie sicher, dass die Karte zurückgegeben wird

Ok, das ist großartig, aber es gibt viele Teile des Systems, die zusammenarbeiten, damit es passieren kann (denken Sie an Account obj, Dispenser obj, Customer obj und so weiter). Für mich sieht das wie ein Integrationstest aus.

Ich hätte gerne Unit Tests. Wie teste ich den Code, der prüft, ob der Spender Geld hat? Oder dass das Geld ausgegeben wird? Oder dass das Konto bei Bedarf belastet wird? Wie kann ich Unit-Tests mit "BA Created" -Tests mischen?

18
JSBach

Verhaltensorientierte Entwicklung und testgetriebene Entwicklung sind kostenlos, aber kein Ersatz für einander.

Wie sich die Anwendung "verhält", wird in Abnahmetests beschrieben, bei denen es sich laut BDD um die in Cucumber geschriebenen Funktionen und Szenarien handelt.

Die Details der Funktionsweise der einzelnen kleinen Komponenten werden in Unit Tests beschrieben. Die Ergebnisse der Komponententests unterstützen die Szenarien, die Sie in Cucumber schreiben.

Stellen Sie sich den Prozess zum Bau eines Autos vor.

Zunächst entwickelt das Produktteam seine Ideen und reduziert sie schließlich auf Nutzungsszenarien:

Scenario: Starting the car
    Given I am standing in front of the drivers door
    When I open the door
    Then the door should lift up DeLorean-style (yeah, baby!)
    When I get into the car
    And turn the key
    Then the engine roars to life

Ich weiß, dass dieses Szenario ein bisschen albern klingt, aber es ist eine sehr hohe, produkt- und endbenutzerorientierte Anforderung. Nur die Tür zu öffnen, den Schlüssel zu drehen und den Motor zu starten, erfordert eine Menge verschiedener Komponenten, die zusammenarbeiten. Dieser eine Test reicht nicht aus, um sicherzustellen, dass das Fahrzeug ordnungsgemäß funktioniert. Sie müssen den Anlasser, die Batterie, die Lichtmaschine, den Schlüssel, den Zündschalter testen - und die Liste geht weiter -, nur um ins Auto zu steigen und es zu starten. Jede dieser Komponenten benötigt ihre eigenen Tests.

Das obige Szenario ist ein "Big Picture" -Test. Jede Komponente des Fahrzeugs benötigt "Small Picture" -Tests, um sicherzustellen, dass sie im gesamten Fahrzeug ordnungsgemäß funktionieren.

Das Erstellen und Testen von Software ist in vielerlei Hinsicht gleich. Sie entwerfen von oben nach unten und bauen dann von unten nach oben. Warum eine Tür, die sich anheben lässt, wenn Sie den Motor nicht einmal starten können? Warum einen Starter haben, wenn Sie keine Batterie haben?

Ihr Produktteam erstellt die Abnahmetests und konkretisiert sie in Gurke. Dies gibt Ihnen das "große Bild". Jetzt ist es an dem Engineering-Team, die richtigen Komponenten und deren Interaktion zu entwerfen und sie dann einzeln zu testen - dies sind Ihre Komponententests.

Sobald die Komponententests bestanden sind, beginnen Sie mit der Implementierung der Gurkenszenarien. Sobald diese verstrichen sind, haben Sie geliefert, was das Produktteam gefragt hat.

28
Greg Burghardt

Ich versuche BDD zu verstehen. Ich habe einige Artikel gelesen und wie ich verstanden habe, ist BDD "der nächste Schritt" von TDD. Ich sage das, weil ich finde, dass beide sehr ähnlich sind und wie ich in diesem Artikel lesen konnte, BDD als eine Verbesserung von TDD geboren wurde.

Nein, BDD ist nicht "der nächste Schritt" von TDD. Es ist TDD. Genauer gesagt handelt es sich um eine Umformulierung von TDD.

Die Entwickler von BDD stellten fest, dass die größte Hürde für das Verständnis, dass es bei TDD nicht um Tests, sondern um Verhaltensspezifikationen geht, darin bestand, dass sich die gesamte TDD-Terminologie auf Tests und nicht auf Verhaltensspezifikationen bezieht. Es ist, als würde man versuchen, nicht an einen rosa Elefanten zu denken, wenn jemand zu Ihnen sagt: "Versuchen Sie, nicht an einen rosa Elefanten zu denken", außer mit der zusätzlichen Komplikation, in einem Raum voller rosa Elefanten zu sein und ständig "rosa Elefant, rosa" zu schreien Elefant, rosa Elefant "in deinem Ohr.

Daher haben sie TDD in Bezug auf die Verhaltensspezifikation umformuliert. "Tests" und "Testfälle" sind jetzt "Beispiele", "Einheiten" sind "Verhaltensweisen", "Behauptungen" sind "Erwartungen" und so weiter.

Die Methodik ist jedoch immer noch dieselbe. Sie beginnen mit einem Abnahmetest (ich meine "Feature"), Vergrößern eines Unit-Tests (ich meine "Beispiel"), Verkleinern usw. .

Ich hätte gerne Unit Tests. Wie teste ich den Code, der prüft, ob der Spender Geld hat? Oder dass das Geld ausgegeben wird? Oder dass das Konto bei Bedarf belastet wird? Wie kann ich Unit-Tests mit "BA Created" -Tests mischen?

Genauso wie bei TDD. Sie können Ihre Funktionen und Beispiele in verschiedenen Frameworks (z. B. Cucumber und RSpec) oder sogar in verschiedenen Sprachen (z. B. Schreiben von Beispielen für ein C-Projekt in C und Funktionen in FIT/Fitnesse) schreiben. Sie können für beide ein einziges Feature-Framework verwenden (z. zB Schreiben von Beispielen und Funktionen in Cucumber) oder Sie können ein einzelnes Beispiel-Framework für beide verwenden (z. B. Schreiben beider in RSpec). Sie müssen überhaupt kein Framework verwenden.

Ein Beispiel für TDD-done-right (das mit BDD identisch ist), das nur ein einziges Framework verwendet, ist JUnit selbst, das eine Mischung aus Komponententests (Beispiele) und Funktions-/Integrationstests (Features) enthält, die alle in JUnit selbst geschrieben sind.

Ich glaube, Kent Beck nennt das "Zoomen". Starten Sie auf hoher Ebene, "zoomen" Sie die Details an und kehren Sie dann wieder zurück.

9
Jörg W Mittag

Haftungsausschluss: Ich bin kein Experte für BDD, aber ich versuche, Ihnen meinen Standpunkt zu dem Artikel zu vermitteln, auf den Sie verlinkt haben.

TDD ist eine Implementierungstechnik. Sie schreiben zuerst einen Test, implementieren dann die Methode, führen Ihren Test aus, überarbeiten ihn und fügen weitere Tests für dieselbe Methode oder für eine neue Methode hinzu. TDD definiert eigentlich keine Regeln für die Auswahl von Klassen- oder Methodennamen, das liegt bei Ihnen. TDD sagt Ihnen auch nicht "wann Sie fertig sind".

Wenn Sie also einen Test für eine neue Methode schreiben, müssen Sie einen Methodennamen auswählen - und genau hier kommt BDD ins Spiel. Wählen Sie Methodennamen anhand der Geschäftsbegriffe aus dem obigen Szenario aus und wählen Sie sie beschreibend aus das Verhalten Ihrer Klasse, machen Sie BDD. Wenn Sie sich fragen, ob ich weitere Tests hinzufügen muss, können Sie die von Ihrem BA angegebenen Szenarien überprüfen und prüfen, ob Sie alle erforderlichen Teile vollständig implementiert haben. Wenn nicht, müssen Sie weitere Tests hinzufügen.

Der Autor des Artikels schlägt außerdem vor, bei der Auswahl der Namen Ihrer Tests ein verhaltensbezogeneres Namensschema zu verwenden. Aus diesem Grund schlägt er vor, JUnit durch ein Tool zu ersetzen, das nicht auf einem Namensschema basiert, mit dem jeder Testfall beginnen muss der Name "Test". Obwohl ich JBehave nicht kenne, denke ich, dass dies der Hauptunterschied zwischen diesem Tool und Junit ist.

Darüber hinaus sind die BDD-Szenarien auch eine Blaupause für Integrationstests - die Sie normalerweise hinzufügen nach Sie haben die Methodennamen durch TDD konkretisiert und nachdem Sie eine angemessene Anzahl von Komponententests hinzugefügt haben.

Nach meinem Verständnis ist TDD ein Instrument, das Sie als Teil von BDD verwenden können, und BDD hilft Ihnen, die richtigen Tests zu schreiben und ihnen bessere Namen zu geben.

1
Doc Brown