Cet article est l'article du 14ème jour du Java Advent Calendar 2016.
L'article du 13e jour a été écrit par tkxlab, "Base de données orientée objet facile (JPA) même avec JavaSE. / items / 11bd9bd93fc0636ee8e8) ". Le 15e jour, kokuzawa's "Histoire équipée de HttpURLConnection"est.
Tout d'abord, permettez-moi d'expliquer brièvement la motivation pour utiliser JGiven.
Si vous voulez juste savoir comment l'utiliser, ignorez cette "Introduction" et lisez "[JGiven Saves](http://qiita.com/enk/items/240e56a00e104d7088d8#jgiven-%E3%81%8C%E6%" Veuillez lire «95% 91% E3% 81% 86)».
En tant que développeurs de logiciels, nous écrivons naturellement des tests unitaires en utilisant JUnit et ainsi de suite.
Cependant, il existe les problèmes suivants.
En plus des tests unitaires, je souhaite également écrire des tests fonctionnels. Cependant, si vous les écrivez tous dans JUnit, la portée des tests exécutés dans ** JUnit sera différente **.
Il est possible de faire la distinction en utilisant des conventions de dénomination et des annotations, mais dans tous les cas, une ingéniosité particulière est requise.
Puisque JUnit est écrit en Java, les développeurs sont libres (bien sûr) de diviser les classes et les méthodes. Les développeurs expérimentés pourront configurer habilement des classes de test, des méthodes, des classes utilitaires, etc. pour écrire des ** tests DRY et faciles à lire **.
Mais à l'inverse, JUnit n'a pas de mécanisme spécial pour prendre en charge la configuration des tests lisible à sec, et il faut des connaissances et de l'expérience pour bien les configurer.
JUnit utilise des conventions de dénomination pour représenter le contenu de test. Par exemple, xUnit Test Patterns suggère les schémas de dénomination suivants:
testRequestApproval_shouldEndUpInAwaitingApproval)
De plus, il est préférable d'inclure l'état à tester et la valeur d'entrée.
Dans tous les cas, peu importe comment vous la concevez, c'est le nom d'une méthode Java et son expressivité est limitée.
De plus, comme le framework n'applique pas la dénomination, il est possible (par exemple) d'oublier d'écrire le comportement attendu, ou pour les nouveaux développeurs de passer inaperçus par les règles et de leur donner de mauvais noms.
Par conséquent, que vous soyez un homme d'affaires, un ingénieur de test ou même l'ingénieur logiciel qui a écrit le test (après un certain temps) **, la simple lecture du rapport de test garantit le type de comportement. Vous pouvez vous retrouver dans une situation où vous ne savez pas si vous êtes **. [^ 1]
[^ 1]: Les ingénieurs logiciels apprécient donc beaucoup la lisibilité de leur code de test. Vous pouvez lire le code de test pour voir ce que vous testez. Cependant, nous ne pouvons pas nous attendre à ce que des professionnels ou des ingénieurs de test qui ne maîtrisent pas le code lisent et comprennent rapidement le code de test.
### Alors je veux BDD
J'ai donc introduit le framework BDD
* Pour la plage un tour (ou plus) au-dessus de l'unité
* D'une manière très expressive de reporting
Je veux écrire un test.
## 100% Java pur
Cependant, de nombreux frameworks BDD nécessitent que vous appreniez et mainteniez votre propre notation pour décrire le comportement.
Les frameworks BDD en Java incluent [JBehave](http://jbehave.org) et [Cucumber-JVM](https://cucumber.io/docs/reference/jvm), mais la description du comportement elle-même est Vous devez le faire en texte brut et l'associer au code Java avec des annotations. [^ 2]
[^ 2]: Un autre est le framework BDD de Groovy appelé [Spock](http://spockframework.org). (Référence: [Apply Spock to Java unit test](http://qiita.com/euno7/items/1e834d3d58da3e659f92)) Puisqu'il s'agit de Groovy, il fonctionne sur la JVM et semble assez expressif, mais Java Dans de nombreux cas, inclure le framework Groovy (bien qu'un code de test) dans un produit peut être une tâche ardue.
Cette méthode présente les inconvénients suivants:
* Il est difficile de se souvenir des descriptions de comportement et des annotations qui associent le code Java
* La quantité de description lors de l'écriture d'un test équivalent est supérieure à celle de JUnit (écrite uniquement en Java)
* La fonction de refactoring de l'EDI ne fonctionne pas pour la partie de notation d'origine, et il est difficile de changer le nom, etc.
Si possible, je souhaite écrire uniquement en Java ...
# JGiven enregistre
Alors JGiven!
## Qu'est-ce que JGiven
Qu'est-ce que JGiven? Cité (traduit) de [Site officiel](http://jgiven.org).
> JGiven est un outil Java BDD convivial et pratique.
> Les développeurs utilisent des API fluides et spécifiques au domaine pour écrire des scénarios en Java (uniquement).
> Les experts du domaine peuvent lire les rapports générés par JGiven.
Oui, vous ne pouvez écrire qu'en Java![^ 3]
[^ 3]: Il y a un inconvénient que les experts du domaine qui ne peuvent pas écrire en Java ne peuvent pas écrire de scénarios directement, mais cela peut être résolu en écrivant par paires avec le développeur. Alternativement, l'expert du domaine pourrait l'écrire dans n'importe quelle notation (qui correspond au framework JGiven) et le développeur pourrait le traduire en code Java. Là encore, le coût est comparable à celui des cadres BDD traditionnels qui nécessitent une association annotée, mais pas plus élevé. Une fois dans le code Java, vous êtes libre de refactoriser avec l'EDI.
Bien sûr, il existe également des rapports faciles à lire.
JGiven permet ** 100% Pure Java BDD **.
## Diverses ressources
Voici différents liens liés à JGiven.
* Site officiel: http://jgiven.org
* GitHub : https://github.com/TNG/JGiven
* Vidéo de conférence par le développeur
* Version longue expliquée à partir des bases de BDD: https://www.youtube.com/watch?v=gh_yjb3x8Yc
* Version courte avec un focus sur les points: https://www.youtube.com/watch?v=x-6bT_0dTWI
* Codage en direct (mais difficile à voir ...): https://www.youtube.com/watch?v=4oFl4nxoshM
Le développement sur GitHub est [actif](https://github.com/TNG/JGiven/commits/master), et les activités de diffusion sont activement menées [^ 4], et bien que ce soit encore un cadre mineur, il est favorable Peut avoir.
[^ 4]: J'ai également eu une session chez JavaOne en 2016 (diapositive: https://janschaefer.github.io/jgiven-slides-javaone-2016/#/)
# Comment utiliser
Vous pouvez découvrir comment l'utiliser en consultant le guide de l'utilisateur.
http://jgiven.org/userguide/
Cela ne suffit pas, je vais donc l'expliquer étape par étape.
## Basiques
Commençons par le déplacer.
### Dépendances
jgiven-core fonctionne avec JUnit ou TestNG.
Avec la dernière version de JGiven 0.12.1 en date du 14/12/2016, JUnit requiert la version 4.9 ou supérieure (4.11 ou supérieure est recommandée).
* Dépendance JUnit Maven / Gradle: http://jgiven.org/userguide/#_junit
* Dépendance Maven / Gradle de TestNG: http://jgiven.org/userguide/#_testng
### Faire le corps
Si vous pouvez résoudre la dépendance, écrivez-la immédiatement.
Les exemples suivants sont expliqués par JUnit.
Commencez par créer le corps de la classe de test.
#### **`MyShinyJGivenTest.java`**
```java
import com.tngtech.jgiven.junit.ScenarioTest;
public class MyShinyJGivenTest
extends ScenarioTest<GivenSomeState, WhenSomeAction, ThenSomeOutcome> {
}
C'est facile.
La classe de test (scénario) de JGiven hérite d'une classe appelée ScenarioTest. ScenarioTest prend trois paramètres de type. Chacun correspond à trois étapes BDD typiques (Donné, Quand, Alors).
En passant, à ce stade, les données GivenSomeState, WhenSomeAction et ThenSomeOutcome de MyShinyJGivenTest n'existent pas encore. Faisons-le.
GivenSomeState.java
import com.tngtech.jgiven.Stage;
public class GivenSomeState extends Stage<GivenSomeState> {
public GivenSomeState Dans un certain état() {
return self();
}
}
WhenSomeAction.java
import com.tngtech.jgiven.Stage;
public class WhenSomeAction extends Stage<WhenSomeAction> {
public WhenSomeAction Si vous faites quelque chose() {
return self();
}
}
ThenSomeOutcome.java
import com.tngtech.jgiven.Stage;
public class ThenSomeOutcome extends Stage<ThenSomeOutcome> {
public ThenSomeOutcome Quelque chose se passe() {
return self();
}
}
Comme c'est un gros problème, j'ai essayé de changer le nom de la méthode en japonais. [^ 5]
[^ 5]: Je pense qu'il y a des avantages et des inconvénients à utiliser le japonais pour le code de test. Chez Apresso, auquel j'appartiens, j'ai utilisé le japonais pour le nom de la méthode de test, et j'ai pu écrire et utiliser le test assez efficacement en termes de descriptivité et de lisibilité. Je vais. Cependant, la situation peut changer à nouveau si les développeurs qui ne peuvent pas lire le japonais participent au développement de produits à l'avenir.
Je suis prêt. Ajoutons un scénario et exécutons-le.
MyShinyJGivenTest.java
import org.junit.Test;
import com.tngtech.jgiven.junit.ScenarioTest;
public class MyShinyJGivenTest
extends ScenarioTest<GivenSomeState, WhenSomeAction, ThenSomeOutcome> {
@Test
vide public quelque chose se passe() {
given().Dans un certain état();
when().Si tu fais quelque chose();
then().Quelque chose se passe();
}
}
Le scénario est ajouté en tant que méthode de test JUnit / TestNG familière et écrit dans cette notation.
Tout d'abord, exécutons-le à partir de IntelliJ IDEA que j'utilise habituellement.
Le framework est JUnit, vous pouvez donc l'exécuter comme un test JUnit comme vous le feriez normalement. Bien sûr, il en va de même pour Eclipse et NetBeans.
Le résultat est sorti sur la console.
Quand j'ai donné un nom bâclé aux scénarios et aux étapes, cela ressemblait de manière inattendue aux paroles de J-POP dans les années 90, mais c'était quand même un succès.
Bien sûr, vous pouvez également le faire à partir de la ligne de commande.
$ mvn test
Étant donné que vous souhaitez automatiser la sortie du rapport, cela peut être l'utilisation principale.
Lorsque vous exécutez un scénario JGiven, deux types de rapports sont générés par défaut.
Le rapport à la console a déjà été vu.
Les rapports aux fichiers JSON sont stockés dans le répertoire `` jgiven-reports / json ''. Voici un moyen rapide de savoir où se trouve ce répertoire dans votre environnement d'exécution. [^ 6]
System.out.println(com.tngtech.jgiven.impl.Config.config().getReportDir().get().getAbsolutePath());
[^ 6]: Référence: https://github.com/TNG/JGiven/blob/8225c0bfc0f8d7e712c2d2aa58a7db24d72a70b5/jgiven-core/src/main/java/com/tngtech/jgiven/impl/Config.java#L30
Eh bien, c'est bien d'avoir un rapport en JSON, mais c'est difficile de lire JSON. Bien sûr, il existe un moyen de le convertir en HTML.
Pour utiliser la fonction de création de rapports HTML5, ajoutez une dépendance à jgiven-html5-report en plus du jgiven-core que vous avez déjà obtenu.
La méthode à exécuter à partir de la ligne de commande est la suivante.
java com.tngtech.jgiven.report.ReportGenerator \
--format=html \
[--sourceDir=<Annuaire avec rapports JSON>] \
[--targetDir=<Le répertoire dans lequel vous souhaitez générer le rapport HTML5>] \
On suppose que jgiven-core et ses modules dépendants, jgiven-html5-report, se trouvent dans le chemin de classe. (Utilisez l'option `` -cp '' si nécessaire)
--sourcedir
/ --targetdir
Si n'est pas spécifié, ce sera le répertoire courant.
Le guide de l'utilisateur montre également comment définir les objectifs / tâches maven et gradle. Veuillez vous y référer si nécessaire.
http://jgiven.org/userguide/#_html_report
Le rapport est là!
Vous pouvez voir qu'il existe de nombreuses fonctions telles que l'affichage du résumé, la classification succès / échec / en attente, la classification des balises / classes, la recherche et l'impression.
Un rapport de test de JGiven lui-même est également fourni à titre d'exemple.
http://jgiven.org/jgiven-report/html5/
Jusqu'à présent, nous avons introduit JGiven, mais nous n'avons pas décrit les classes et les assertions cibles de test essentielles, nous ne pouvons donc pas dire que nous avons encore pu l'utiliser. Dans les prochains jours, nous publierons "100% Pure Java BDD (Practice) with JGiven".
Recommended Posts