Dieser Artikel ist der 14. Tagesartikel von Java Adventskalender 2016.
Der Artikel am 13. Tag wurde von tkxlab "Easy Database-Object Oriented Database (JPA) mit Java SE geschrieben. / items / 11bd9bd93fc0636ee8e8) ". Am 15. Tag kokuzawas "Story mit HttpURLConnection "ist.
Lassen Sie mich zunächst kurz die Motivation für die Verwendung von JGiven erläutern.
Wenn Sie nur wissen möchten, wie es verwendet wird, überspringen Sie diese "Einführung" und lesen Sie "[JGiven Saves](http://qiita.com/enk/items/240e56a00e104d7088d8#jgiven-%E3%81%8C%E6%". Bitte lesen Sie aus "95% 91% E3% 81% 86)".
Als Softwareentwickler schreiben wir natürlich Unit-Tests mit JUnit und so weiter.
Es gibt jedoch die folgenden Probleme.
Neben Unit-Tests möchte ich auch Funktionstests schreiben. Wenn Sie sie jedoch alle in JUnit schreiben, ist der Umfang der in ** JUnit ausgeführten Tests unterschiedlich **.
Es kann durch Namenskonventionen und Anmerkungen unterschieden werden, aber in jedem Fall ist besonderer Einfallsreichtum erforderlich.
Da JUnit in Java geschrieben ist, können Entwickler (natürlich) Klassen und Methoden aufteilen. Erfahrene Entwickler können Testklassen, Methoden, Dienstprogrammklassen usw. geschickt konfigurieren, um ** DRY- und einfach zu lesende Tests ** zu schreiben.
Umgekehrt verfügt JUnit jedoch nicht über einen speziellen Mechanismus zur Unterstützung der DRY-lesbaren Konfiguration von Tests, und es sind einige Kenntnisse und Erfahrungen erforderlich, um sie gut zu konfigurieren.
JUnit verwendet Namenskonventionen, um Testinhalte darzustellen. Beispielsweise schlägt xUnit Test Patterns die folgenden Benennungsschemata vor:
testRequestApproval_shouldEndUpInAwaitingApproval)
Außerdem ist es besser, den zu testenden Zustand und den Eingabewert anzugeben.
Unabhängig davon, wie Sie es entwickeln, ist es auf jeden Fall der Name einer Java-Methode und ihre Ausdruckskraft ist begrenzt.
Da das Framework die Benennung nicht erzwingt, kann es beispielsweise passieren, dass Sie vergessen, das erwartete Verhalten zu schreiben, oder dass neue Entwickler von den Regeln unbemerkt bleiben und ihnen schlechte Namen geben.
Unabhängig davon, ob Sie ein Unternehmer, ein Testingenieur oder sogar der Softwareentwickler sind, der den Test (nach einer Weile) geschrieben hat, ** garantiert das Lesen des Testberichts, welche Art von Vorgang ausgeführt wird. Sie könnten in eine Situation geraten, in der Sie nicht wissen, ob Sie ** sind. [^ 1]
[^ 1]: Softwareentwickler schätzen daher die Lesbarkeit ihres Testcodes sehr. Sie können den Testcode lesen, um zu sehen, was Sie testen. Wir können jedoch nicht erwarten, dass Geschäftsleute oder Testingenieure, die nicht gut mit Code umgehen können, den Testcode schnell lesen und verstehen.
### Also möchte ich BDD
Also habe ich das BDD Framework eingeführt und
* Für den Bereich eine Runde (oder mehr) über dem Gerät
* In einer sehr ausdrucksstarken Art der Berichterstattung
Ich möchte einen Test schreiben.
## 100% reines Java
Bei vielen BDD-Frameworks müssen Sie jedoch Ihre eigene Notation zur Beschreibung des Verhaltens lernen und beibehalten.
Zu den BDD-Frameworks in Java gehören [JBehave](http://jbehave.org) und [Cucumber-JVM](https://cucumber.io/docs/reference/jvm), die Verhaltensbeschreibung selbst lautet jedoch Sie müssen dies im Klartext tun und es mit Java-Code mit Anmerkungen verknüpfen. [^ 2]
[^ 2]: Ein weiteres ist Groovys BDD-Framework namens [Spock](http://spockframework.org). (Referenz: [Spock auf Java-Komponententest anwenden](http://qiita.com/euno7/items/1e834d3d58da3e659f92)) Da es Groovy ist, funktioniert es auf der JVM und scheint ziemlich ausdrucksstark zu sein, aber Java In vielen Fällen ist es ziemlich schwierig, das Groovy-Framework in ein Produkt aufzunehmen (wenn auch einen Testcode).
Diese Methode hat die folgenden Nachteile:
* Es ist schwierig, sich an die Anmerkung zu erinnern, die die Verhaltensbeschreibung und den Java-Code verknüpft.
* Der Umfang der Beschreibung beim Schreiben eines äquivalenten Tests ist größer als der von JUnit (nur in Java geschrieben).
* Die Refactoring-Funktion der IDE funktioniert nicht für den ursprünglichen Notationsteil, und es ist schwierig, den Namen usw. zu ändern.
Wenn möglich möchte ich nur in Java schreiben ....
# JGiven spart
Also JGiven!
## Was ist JGiven?
Ich werde zitieren (übersetzen), was JGiven von der [offiziellen Seite](http://jgiven.org) ist.
> JGiven ist ein entwicklerfreundliches und praktisches Java BDD-Tool.
> Entwickler verwenden fließende, domänenspezifische APIs, um Szenarien (nur) in Java zu schreiben.
> Domain-Experten können von JGiven erstellte Berichte lesen.
Ja, Sie können nur in Java schreiben![^ 3]
[^ 3]: Es gibt einen Nachteil, dass Domain-Experten, die kein Java schreiben können, keine Szenarien direkt schreiben können. Dies kann jedoch durch paarweises Schreiben mit dem Entwickler gelöst werden. Alternativ könnte der Domain-Experte es in einer beliebigen Notation schreiben (die zum JGiven-Framework passt) und der Entwickler könnte es in Java-Code übersetzen. Auch hier sind die Kosten vergleichbar mit herkömmlichen BDD-Frameworks, für die Anmerkungen erforderlich sind, jedoch nicht höher. Sobald Sie sich im Java-Code befinden, können Sie die IDE neu gestalten.
Natürlich gibt es auch leicht zu lesende Berichte.
JGiven aktiviert ** 100% Pure Java BDD **.
## Verschiedene Ressourcen
Hier sind verschiedene Links zu JGiven.
* Offizielle Website: http://jgiven.org
* GitHub : https://github.com/TNG/JGiven
* Vorlesungsvideo des Entwicklers
* Lange Version erklärt anhand der Grundlagen von BDD: https://www.youtube.com/watch?v=gh_yjb3x8Yc
* Kurzversion mit Schwerpunkt auf den Punkten: https://www.youtube.com/watch?v=x-6bT_0dTWI
* Live-Codierung (aber schwer zu sehen ...): https://www.youtube.com/watch?v=4oFl4nxoshM
Die Entwicklung auf GitHub ist [aktiv](https://github.com/TNG/JGiven/commits/master), und Verbreitungsaktivitäten werden aktiv durchgeführt [^ 4], und obwohl es sich immer noch um einen kleinen Rahmen handelt, ist dies günstig. Kann haben.
[^ 4]: Ich hatte 2016 auch eine Sitzung bei JavaOne (Folie: https://janschaefer.github.io/jgiven-slides-javaone-2016/#/)
# Wie benutzt man
Informationen zur Verwendung finden Sie in der Bedienungsanleitung.
http://jgiven.org/userguide/
Das ist nicht genug, deshalb werde ich es Schritt für Schritt erklären.
## Grundlagen
Bewegen wir es zuerst.
### Abhängigkeiten
jgiven-core funktioniert mit JUnit oder TestNG.
Mit dem neuesten JGiven 0.12.1 vom 14.12.2016 benötigt JUnit 4.9 oder höher (4.11 oder höher wird empfohlen).
* JUnit Maven / Gradle-Abhängigkeit: http://jgiven.org/userguide/#_junit
* TestNG Maven / Gradle-Abhängigkeit: http://jgiven.org/userguide/#_testng
### Mach den Körper
Wenn Sie die Abhängigkeit auflösen können, schreiben Sie sie sofort.
Die folgenden Beispiele werden von JUnit erläutert.
Erstellen Sie zunächst den Hauptteil der Testklasse.
#### **`MyShinyJGivenTest.java`**
```java
import com.tngtech.jgiven.junit.ScenarioTest;
public class MyShinyJGivenTest
extends ScenarioTest<GivenSomeState, WhenSomeAction, ThenSomeOutcome> {
}
Es ist einfach.
Die Testklasse (Szenario) von JGiven erbt von einer Klasse namens ScenarioTest. ScenarioTest verwendet drei Typparameter. Jeder entspricht drei typischen BDD-Schritten (Gegeben, Wann, Dann).
Nun, zu diesem Zeitpunkt existieren MyShinyJGivenTests GivenSomeState, WhenSomeAction und ThenSomeOutcome noch nicht. Lass es uns machen.
GivenSomeState.java
import com.tngtech.jgiven.Stage;
public class GivenSomeState extends Stage<GivenSomeState> {
public GivenSomeState In einem bestimmten Zustand() {
return self();
}
}
WhenSomeAction.java
import com.tngtech.jgiven.Stage;
public class WhenSomeAction extends Stage<WhenSomeAction> {
public WhenSomeAction Wenn Sie etwas tun() {
return self();
}
}
ThenSomeOutcome.java
import com.tngtech.jgiven.Stage;
public class ThenSomeOutcome extends Stage<ThenSomeOutcome> {
public ThenSomeOutcome Es passiert etwas() {
return self();
}
}
Da es eine große Sache ist, habe ich versucht, den Methodennamen in Japanisch zu ändern. [^ 5]
[^ 5]: Ich denke, es gibt Vor- und Nachteile, Japanisch für den Testcode zu verwenden. Bei Apresso, zu dem ich gehöre, habe ich Japanisch für den Namen der Testmethode verwendet, und ich konnte den Test sowohl hinsichtlich der Beschreibbarkeit als auch der Lesbarkeit recht effizient schreiben und verwenden. Ich werde. Die Situation kann sich jedoch erneut ändern, wenn Entwickler, die kein Japanisch lesen können, in Zukunft an der Produktentwicklung teilnehmen.
Ich bin bereit. Fügen wir ein Szenario hinzu und führen es aus.
MyShinyJGivenTest.java
import org.junit.Test;
import com.tngtech.jgiven.junit.ScenarioTest;
public class MyShinyJGivenTest
extends ScenarioTest<GivenSomeState, WhenSomeAction, ThenSomeOutcome> {
@Test
öffentliche Leere etwas passiert() {
given().In einem bestimmten Zustand();
when().Wenn du etwas tust();
then().Etwas passiert();
}
}
Das Szenario wird als vertraute JUnit / TestNG-Testmethode hinzugefügt und in dieser Notation geschrieben.
Lassen Sie es uns zunächst mit der IntelliJ IDEA ausführen, die ich normalerweise verwende.
Das Framework ist JUnit, sodass Sie es wie gewohnt als JUnit-Test ausführen können. Gleiches gilt natürlich auch für Eclipse und NetBeans.
Das Ergebnis wird an die Konsole ausgegeben.
Als ich den Szenarien und Schritten einen schlampigen Namen gab, sah es unerwartet aus wie die Texte von J-POP in den 90ern, aber es war trotzdem ein Erfolg.
Natürlich können Sie dies auch über die Befehlszeile tun.
$ mvn test
In Anbetracht dessen, dass Sie die Ausgabe des Berichts automatisieren möchten, kann dies die Hauptverwendung sein.
Wenn Sie ein JGiven-Szenario ausführen, werden standardmäßig zwei Arten von Berichten ausgegeben.
Der Bericht an die Konsole wurde bereits angezeigt.
Berichte in JSON-Dateien werden im Verzeichnis `` `jgiven-reports / json``` gespeichert. Hier finden Sie eine schnelle Möglichkeit, um herauszufinden, wo sich dieses Verzeichnis in Ihrer laufenden Umgebung befindet. [^ 6]
System.out.println(com.tngtech.jgiven.impl.Config.config().getReportDir().get().getAbsolutePath());
[^ 6]: Referenz: https://github.com/TNG/JGiven/blob/8225c0bfc0f8d7e712c2d2aa58a7db24d72a70b5/jgiven-core/src/main/java/com/tngtech/jgiven/impl/Configj
Es ist schön, einen Bericht in JSON zu haben, aber es ist schwer, JSON zu lesen. Natürlich gibt es eine Möglichkeit, es in HTML zu konvertieren.
Um die HTML5-Berichtsfunktion zu verwenden, fügen Sie zusätzlich zu dem bereits erhaltenen jgiven-core eine Abhängigkeit von jgiven-html5-report hinzu.
Die Methode, die über die Befehlszeile ausgeführt werden soll, lautet wie folgt.
java com.tngtech.jgiven.report.ReportGenerator \
--format=html \
[--sourceDir=<Verzeichnis mit JSON-Berichten>] \
[--targetDir=<Das Verzeichnis, in dem Sie den HTML5-Bericht ausgeben möchten>] \
Es wird angenommen, dass sich jgiven-core und seine abhängigen Module, jgiven-html5-report, im Klassenpfad befinden. (Verwenden Sie ggf. die Option `` `-cp)
--sourcedir/
--targetdir```Wenn nicht angegeben, ist dies das aktuelle Verzeichnis.
Das Benutzerhandbuch zeigt auch, wie Maven- und Gradle-Ziele / Aufgaben definiert werden. Bitte beziehen Sie sich bei Bedarf darauf.
http://jgiven.org/userguide/#_html_report
Der Bericht ist da!
Sie können sehen, dass es viele Funktionen gibt, wie z. B. Zusammenfassungsanzeige, Erfolg / Misserfolg / ausstehende Klassifizierung, Tag- / Klassenklassifizierung, Suche und Drucken.
Ein Testbericht von JGiven selbst wird ebenfalls als Beispiel bereitgestellt.
http://jgiven.org/jgiven-report/html5/
Bisher haben wir JGiven eingeführt, aber wir haben die wesentlichen Testzielklassen und Behauptungen nicht beschrieben, sodass wir nicht sagen können, dass wir es bereits nutzen konnten. In den nächsten Tagen werden wir "100% Pure Java BDD (Practice) with JGiven" veröffentlichen.
Recommended Posts