Doublures Mockito
Simulacre, espion, vérification d'interaction, et le test qui se teste lui-même.
Doublures de test avec Mockito
Voici un test qui passe, qui compte dans la couverture, et qui ne détecte strictement rien :
@Test
void le_service_retourne_le_client() {
when(depot.parId(7L)).thenReturn(new Client(7L, "Dupont"));
Client client = service.trouver(7L);
assertThat(client.nom()).isEqualTo("Dupont");
}
Vous avez déclaré que le dépôt renvoie « Dupont », puis vérifié qu'il en sort « Dupont ». Le seul comportement testé est celui de Mockito. Remplacez l'implémentation de service.trouver par return depot.parId(id); en supprimant toute la logique métier qu'elle contenait : le test reste vert. C'est le défaut le plus répandu des suites qui abusent des doublures, et il est indétectable au compteur de couverture, qui affichera fièrement 100 % sur la méthode.
Mockito est un excellent outil mal utilisé par défaut. Le réflexe « une classe testée, tous les collaborateurs simulés » produit des tests qui décrivent la structure interne du code au lieu de son comportement : chaque déplacement de responsabilité entre deux classes casse dix tests sans qu'aucun bug n'ait été introduit. Cette leçon pose une règle simple pour décider quand une doublure est justifiée, et montre comment vérifier des interactions sans se peindre dans un coin.
Commentaires
Les commentaires sont alimentés par GitHub Discussions
Connectez-vous avec GitHub pour participer à la discussion