Dieser Artikel ist der 14. Tag von Apresso Adventskalender 2017.
Behavior Driven Development, eine Abkürzung für Behavior Driven Development. Es erscheint im Zusammenhang mit der Verbesserung der Softwareentwicklungsmethoden. Dies ist eine Entwicklungsmethode, die näher an der Phase der Anforderungsanalyse liegt als TDD (testgetriebene Entwicklung).
Die folgenden Artikel helfen Ihnen zu verstehen, was TDD und BDD in Softwareentwicklungsmethoden bedeuten. Verhaltensgesteuerte Entwicklungsschritte aus dem Wasserfallmodell
Es geht darum, sich auf Funktionen zu konzentrieren und den Zyklus der Anforderungsanalyse, des Designs, der Codierung und des Testens zu durchlaufen, um sich dadurch schneller zu entwickeln und freizugeben (agil).
Wenn man sich das BDD-Framework von Java ansieht, scheint es viele zu geben.
Cucumber Ein Standard-BDD-Framework, das in verschiedenen Sprachen verwendet werden kann, nicht nur in Java. Der Vorteil ist, dass Entwickler, Tester und Geschäftsleute (Geschäftsleute) Wissen austauschen können. Die Funktion (Verhalten) wird in einer einzigartigen Sprache namens Gurke beschrieben.
Gherkins japanische Lesart ist übrigens "Gherkin", eine kleine Gurke, die eingelegt werden muss. Honke-Site
JBehave Dies scheint nur Java zu sein, aber es scheint ein Framework zu sein, das so beliebt ist wie Cucumber. Die Funktion besteht darin, dass Funktionen (Tests) im Format Sinario (Szenario, User Story), Gegeben (Voraussetzung), Wann (Testfall), Dann (Verhalten wie es sein sollte) beschrieben werden können. Honke-Site
Beispiel Sinario: "Test auf Bestandsalarm. Test, um festzustellen, ob ein bestimmter Bestand über dem Schwellenwert liegt." Gegeben: "Setzen Sie die Aktienkursschwelle auf 1500 Yen" Wann: "Wenn der Aktienkurs 500 Yen beträgt" Dann: "Alarmstatus ist AUS" Wann: "Wenn der Aktienkurs 1600 Yen beträgt" Dann: "Alarmstatus ist EIN"
JGiven Dies wird ausführlich in Artikel aus dem letzten Jahr von @enk, demselben Apresso-Ingenieur, beschrieben, daher überlasse ich die Erklärung dem.
Es scheint, dass der Vorteil darin besteht, dass die gesamte Arbeit nur mit Java abgeschlossen wird.
Ist es ein Tool, das JUnit mit der Idee von Given, When, Then wie JBehave schreiben kann?
Spectrum Dies ist das Java BDD Framework, das ich dieses Mal vorstellen möchte. Ich denke, es ist eher wie bei JGiven. GitHub
Dies liegt daran, dass es einfach einzuführen ist.
Cucumber und JBehave beschreiben das Verhalten in einer Textdatei und integrieren es schließlich in JUnit. Dies liegt wahrscheinlich daran, dass der letzte der drei Charaktere, die Cucumber sich vorstellt (Entwickler, Tester, Unternehmer, Produktbesitzer?), Ebenfalls teilnehmen wird. Es kann gut sein, BDD in der groß angelegten Entwicklung "richtig" zu machen. Es gibt viele Dinge vorzubereiten und sich daran zu erinnern, und ich denke, dass die Schwelle für alle hoch ist.
JGiven ist ein entwicklerfreundlicheres Framework, mit dem Sie Ihr Verhalten in Java-Code ausdrücken können. Der Schwerpunkt liegt auf Entwicklern, die Tests mit der Idee von BDD schreiben. Natürlich wird der Testbericht auch in einem Format ausgegeben, das sich auf die Funktion konzentriert, sodass auch andere Zeichen als der Entwickler davon profitieren können. Ich muss jedoch zusätzlich zur Testklasse Status-, Aktions- und Ergebnisklassen erstellen, und es scheint schwierig (obwohl ich dies nicht bestätigt habe), sie mit vorhandenen Tests zu mischen.
Da die Substanz von Spectrum eine Erweiterung von JUit ist, muss keine andere Klasse als die Testklasse erstellt werden, und da sie mit dem vorhandenen JUnit-Test gemischt werden kann, kann sie teilweise eingeführt werden.
Fügen Sie die Spektrum-JAR-Datei zum Klassenpfad hinzu.
Gradle Fügen Sie den Abhängigkeiten von build.gradle die folgende Zeile hinzu.
Für die Java-Bibliothek
testImplementation 'com.greghaskins:spectrum:1.2.0'
Andernfalls
#### **`testCompile 'com.greghaskins:spectrum:1.2.0'`**
Maven Fügen Sie den Abhängigkeiten in pom.xml Folgendes hinzu.
<dependency>
<groupId>com.greghaskins</groupId>
<artifactId>spectrum</artifactId>
<version>1.2.0</version>
<scope>test</scope>
</dependency>
Laden Sie es aus dem Maven Central Repository (https://mvnrepository.com/artifact/com.greghaskins/spectrum) herunter und fügen Sie es Ihrem Klassenpfad hinzu.
Ich habe den zu testenden Code vorbereitet, Tests in drei Arten von Spec-Format, Gherkin-Format und Junit-Format erstellt und verglichen.
Bereiten Sie das folgende Testziel vor.
StockWatcher.java
public class StockWatcher {
private int threshold;
public int getThreshold() {
return threshold;
}
public void setThreshold(int threshold) {
this.threshold = threshold;
}
public boolean getAlert(int stockPrice) {
return threshold <= stockPrice;
}
}
Wenn Sie einen Test im Spec-Format schreiben, können Sie ihn wie folgt schreiben.
StockWatcherSpecTest.java
import static org.junit.Assert.*;
import static com.greghaskins.spectrum.dsl.specification.Specification.*; //Spektrumspezifisch
import java.util.function.Supplier;
import org.junit.runner.RunWith;
import com.greghaskins.spectrum.Spectrum; //Spektrumspezifisch
/**
*Spezifikationsformattest
* describe -Sie können Tests in diesem Format schreiben
*/
@RunWith(Spectrum.class)
public class StockWatcherSpecTest {{
//Beschreiben Sie die Spezifikation mit beschreiben
describe("Testen Sie Lagerwarnungen. Ein Test, um festzustellen, ob ein bestimmter Aktienkurs über dem Schwellenwert liegt.", ()->{
//beschreiben kann verschachtelt werden
describe("Stellen Sie den Aktienkursschwellenwert auf 1500 Yen ein", ()->{
//Mit let können Sie ein Testziel erstellen
Supplier<StockWatcher> stockWatcher = let(() -> {
StockWatcher w = new StockWatcher();
w.setThreshold(1500);
return w;
});
describe("Wenn der Aktienkurs 500 Yen beträgt", ()->{
//es entspricht dem Testfall
it("Der Alarmstatus ist AUS", () -> {
assertFalse(stockWatcher.get().getAlert(500));
});
});
describe("Wenn der Aktienkurs 1600 Yen beträgt", ()->{
it("Der Alarmstatus ist EIN", () -> {
assertTrue(stockWatcher.get().getAlert(1600));
});
});
});
});
}}
Wenn ich es in Eclipse laufen lasse, sieht es so aus.
Wenn Sie den Test im Gurkenformat schreiben, können Sie ihn wie folgt schreiben.
StockWatcherGerkinTest.java
import static org.junit.Assert.*;
import static com.greghaskins.spectrum.dsl.gherkin.Gherkin.*; //Spektrumspezifisch
import org.junit.runner.RunWith;
import com.greghaskins.spectrum.Spectrum; //Spektrumspezifisch
import com.greghaskins.spectrum.Variable;
/**
*Gurkenformat-Test
* feature, scenario, given, when,Sie können Tests in diesem Format schreiben
*/
@RunWith(Spectrum.class)
public class StockWatcherGherkinTest {{
feature("Testen Sie Lagerwarnungen.", () -> {
scenario("Ein Test, um festzustellen, ob ein bestimmter Aktienkurs über dem Schwellenwert liegt.", () -> {
StockWatcher w = new StockWatcher();
final Variable<Boolean> alert = new Variable<>();
given("Stellen Sie den Aktienkursschwellenwert auf 1500 Yen ein", () -> {
w.setThreshold(1500);
});
when("Wenn der Aktienkurs 500 Yen beträgt", () -> {
alert.set(w.getAlert(500));
});
then("Der Alarmstatus ist AUS", () -> {
assertFalse(alert.get());
});
});
scenario("Ein Test, um festzustellen, ob ein bestimmter Aktienkurs über dem Schwellenwert liegt.", () -> {
StockWatcher w = new StockWatcher();
final Variable<Boolean> alert = new Variable<>();
given("Stellen Sie den Aktienkursschwellenwert auf 1500 Yen ein", () -> {
w.setThreshold(1500);
});
when("Wenn der Aktienkurs 1600 Yen beträgt", () -> {
alert.set(w.getAlert(1600));
});
then("Der Alarmstatus ist AUS", () -> {
assertTrue(alert.get());
});
});
});
}}
Wenn ich es in Eclipse laufen lasse, sieht es so aus.
Mit der herkömmlichen Schreibmethode können Sie wie folgt schreiben.
StockWatcherJunitTest.java
import static org.junit.Assert.*;
import org.junit.Test;
/**
*Traditioneller JUnit-Formattest
*/
public class StockWatcherJunitTest {
@Test
public void Wenn die Aktienkursschwelle 1500 Yen beträgt_Der Alarmstatus ist AUS für einen Aktienkurs von 500 Yen.() {
StockWatcher w = new StockWatcher();
w.setThreshold(1500);
assertFalse(w.getAlert(500));
}
@Test
public void Wenn die Aktienkursschwelle 1500 Yen beträgt_Der Alarmstatus ist EIN für einen Aktienkurs von 1600 Yen() {
StockWatcher w = new StockWatcher();
w.setThreshold(1500);
assertTrue(w.getAlert(1600));
}
}
Wenn ich es in Eclipse laufen lasse, sieht es so aus.
Als ich den Testbericht von Gradle erstellt habe, habe ich ungefähr Folgendes erhalten:
Im Fall des Spec-Formats wird anscheinend nur die damit gepaarte Beschreibung als Testklasse behandelt. Fälle im Gurkenstil werden szenarioweise als Testklassen behandelt.
Das Ergebnis im Spec-Format.
Das Ergebnis im Gurkenformat.
Dies ist das Ergebnis im JUnit-Format.
Sie können den BDD-Stil nur ändern, um den Test zu schreiben, ohne den herkömmlichen Mechanismus (JUnit) zu ändern. BDD kann schrittweise eingebaut werden, indem es teilweise eingeführt wird.
Obwohl die Spezifikationen in japanischen Sätzen beschrieben werden können, entspricht der Bericht nicht den Quellcodesätzen. Beispielsweise werden Sätze, die außerhalb der verschachtelten Beschreibung geschrieben wurden, und Sätze, die in der Funktion geschrieben wurden, nicht in den Bericht ausgegeben. Je länger der Text ist, desto weniger können Sie den Links im Bericht folgen. Die Ursache ist, dass die in Beschreibung usw. geschriebene Zeichenfolge für den Dateinamen der HTML-Datei des Berichts verwendet wird. Wenn der Satz lang ist, kann er die Begrenzung der Länge des Dateinamens des Betriebssystems überschreiten. (Siehe Abbildung unten)
Im Gurkenformat wird angegeben, wann und dann als Testfälle behandelt, was die Anzahl der Ergebnisse erhöht. (Gegeben, wann wird das natürlich gelingen.) Bei der Ausgabe in einen Bericht werden Testfälle sortiert und in aufsteigender alphabetischer Reihenfolge angezeigt. Wenn Sie also mehrere gegebene schreiben, wenn im selben Szenario nur alle gegeben sind Es wird zuerst angezeigt und ist schwer zu sehen. Selbst wenn es nur eine Kombination von gegeben gibt, wann, dann wird die Reihenfolge gegeben, dann, wann, was immer noch schwer zu sehen ist. Es ist weit von JGivens Bericht entfernt.
Wenn der Bericht nicht der Beschreibung des Quellcodes entspricht, ist es für Nichtentwickler schwierig, an BDD teilzunehmen.
Spectrum ist ein Framework, mit dem Sie Testskripte im BDD-Stil erstellen können, ohne den herkömmlichen JUnit-Testmechanismus zu ändern. Ich dachte, es wäre gut, es probeweise einzuführen und nach und nach BDD zu üben.
Es fällt mir jedoch schwer, den BDD tatsächlich einzuschalten, da die Ausgabe des Testberichts nicht vollständig der Beschreibung des Quellcodes entspricht: sob :.
Site, die BDD-Frameworks unabhängig von einer bestimmten Sprache (Englisch) abdeckt
Recommended Posts