Javadoc dans les classes de test de Junit?
Est-il conseillé de mettre des commentaires Javadoc dans junit test de classes et de méthodes? Ou est l'idée qu'ils doivent être vraiment facile à lire et simple qu'il est inutile de fournir une description de l'essai l'intention?
3 réponses
personnellement j'utilise les commentaires javadoc avec parcimonie, car je trouve qu'elles augmentent l'encombrement à l'écran. Si je peux nommer une classe, une fonction ou une variable d'une manière plus auto-descriptive, alors je préférerai un commentaire. Un excellent livre à lire sur ce sujet est Code Propre par Robert C. Martin(A. K. un oncle Bob).
Ma préférence personnelle est de rendre la classe et les méthodes auto descriptives i.e.
class ANewEventManager {
@Test
public void shouldAllowClassesToSubscribeToEvents() {
/* Test logic here */
}
}
l'avantage de cette approche est qu'il est facile à voir dans la sortie de junit ce qui ne fonctionne pas avant de parcourir le code.
J'utilise souvent Javadoc dans mes tests. Mais il n'est vraiment utile que lorsque vous ajoutez votre propre balise à votre javadoc.
L'objectif principal ici est d' rendre le test compréhensible pour les autres développeurs qui contribuent à votre projet. Et pour cela nous n'avons même pas besoin de générer une réelle javadoc.
/**
* Create a valid account.
* @result Account will be persisted without any errors,
* and Account.getId() will no longer be <code>null</code>
*/
@Test
public void createValidAccount() {
accountService.create(account);
assertNotNull(account.getId());
}
ensuite, nous aurons besoin d'informer notre plugin Javadoc dans maven que nous avons ajouté une nouvelle balise.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.8</version>
<configuration>
<tags>
<tag>
<name>result</name>
<placement>a</placement>
<head>Test assertion :</head>
</tag>
</tags>
</configuration>
</plugin>
</plugins>
</build>
Et maintenant tout ce qui reste à faire est d'appeler notre plugin maven.
javadoc:test-javadoc (or javadoc:test-aggregate for multi-module projects)
ceci est un exemple assez facile, mais quand on exécute des tests plus complexes, il est impossible de décrire les tests en utilisant simplement un nom de méthode auto-descriptif.
j'aime bien aussi les commentaires en UT, elle aide à comprendre les cas d'utilisation en quelques secondes.
j'ai créé une petite bibliothèque pour inclure des descriptions dans le stacktrace de n'importe quel type de rapport, n'importe qui qui vérifie les rapports peut facilement entrer dans le problème.
le nom de La bibliothèque est Frutilla, n'hésitez pas à l'utiliser https://github.com/ignaciotcrespo/frutilla