Anatomie d'un test unitaire
Ce dont est fait un test unitaire JUnit : la classe de test, l'annotation @Test, le montage, le plan Préparer-Agir-Vérifier, un test par comportement, des tests indépendants et un nom qui dit ce qu'on vérifie.
- 24 cartes
- 3 thèmes
- Gratuit
Le programme, thème par thème
Le poids de chaque thème suit celui que lui donne l'examen.
- Notions
- Questions
- Ranger et relier
Quelques cartes du deck
Test unitaire : de quoi s'agit-il ?
Voir la réponse
Petit programme qui exécute une seule unité de code (une méthode, une classe) isolée du reste et vérifie son résultat automatiquement.
Il répond par réussite ou échec sans qu'un humain lise une sortie : on peut donc le rejouer des centaines de fois.
Que vaut
compteurau début de chaque test de cette classe JUnit 5 (configuration par défaut) ?
```java
class CompteurTest {
int compteur = 0;
@Test
void premier() {
compteur++;
assertEquals(1, compteur);
}
@Test
void second() {
compteur++;
assertEquals(1, compteur);
}
}`- 0 : JUnit crée une nouvelle instance de la classe pour chaque test
- 0 pour le premier test lancé, puis 1 pour le suivant : le champ garde sa valeur
- 1 pour les deux : l'initialisation est rejouée après l'incrément
- Une erreur de compilation : un champ ne peut pas être modifié par deux méthodes
Voir la réponse
0 : JUnit crée une nouvelle instance de la classe pour chaque test
JUnit 5 instancie la classe de test une fois par méthode de test : un champ d'instance est donc neuf à chaque test et les deux assertions réussissent. Un champ
static, lui, serait partagé et ferait dépendre un test de l'autre.En JUnit 5, une méthode devient un test quand elle porte l'annotation … ; elle est déclarée sans valeur de retour, donc ….
Voir la réponse
En JUnit 5, une méthode devient un test quand elle porte l'annotation @Test ; elle est déclarée sans valeur de retour, donc void.
Une méthode
@Testqui renvoie une valeur est ignorée par JUnit 5 : elle n'est tout simplement pas exécutée comme test.Système sous test : de quoi s'agit-il ?
Voir la réponse
Le morceau de code précis qu'un test appelle pour en vérifier le comportement.
Un test porte sur lui seul : si le test échoue, le coupable est cherché dans ce morceau de code, pas dans tout le projet.
Ce test réussit toujours, même si
ajouterne fait plus rien. Quel est le défaut ?
```java
@Test
void ajouterUnLivre() {
Panier p = new Panier();
p.ajouter("Dune");
}`- Il crée le panier dans le test au lieu de le créer dans un @BeforeEach
- Il ne contient aucune assertion : rien ne peut le faire échouer
- Il n'est pas public, donc JUnit ne le trouve pas
- Il appelle une seule méthode de Panier, ce qui est insuffisant pour un test
Voir la réponse
Il ne contient aucune assertion : rien ne peut le faire échouer
Un test réussit tant qu'aucune exception ne sort : sans assertion, il ne prouve rien. Il manque par exemple
assertEquals(1, p.taille());. Une méthode de test peut très bien rester sans modificateur d'accès en JUnit 5.