EnglishCommencer

Les doublures de test

Remplacer une dépendance pendant un test : les cinq doublures (fantôme, bouchon, espion, simulacre, substitut), programmer une réponse, vérifier une interaction, et décider ce qu'on double ou ce qu'on laisse réel, avec Mockito.

  • 24 cartes
  • 4 thèmes
  • Gratuit
Réviser ce deck

Le programme, thème par thème

Le poids de chaque thème suit celui que lui donne l'examen.

  1. Notions
  2. Questions
  3. Ranger et relier
  4. Mises en situation

Quelques cartes du deck

  • Doublure de test : de quoi s'agit-il ?

    Voir la réponse

    Objet fabriqué pour un test, qui remplace une dépendance réelle du code testé.

    On remplace une dépendance lente, aléatoire ou hors de contrôle (réseau, horloge, paiement) pour que le test soit rapide et reproductible. Il existe cinq sortes de doublures.

  • Que vaut c dans ce test ?

    ```java
    Depot depot = mock(Depot.class);
    Client c = depot.trouver(42);
    `

    • null
    • Un Client vide, créé par le constructeur par défaut
    • Rien : la ligne lève une MockitoException car aucune réponse n'est programmée
    • Le vrai client numéro 42, lu dans la vraie base par la doublure
    Voir la réponse

    null

    Un mock Mockito non programmé renvoie la valeur par défaut du type : null pour un objet, 0 pour un entier, une liste vide pour une liste. Il n'exécute jamais le vrai code et ne lève rien.

  • Un … sert à contrôler ce que le code testé reçoit ; un … sert à vérifier ce que le code testé envoie.

    Voir la réponse

    Un bouchon sert à contrôler ce que le code testé reçoit ; un simulacre sert à vérifier ce que le code testé envoie.

    Les deux remplacent une dépendance, mais dans des sens opposés : le bouchon alimente le code, le simulacre observe ses sorties.

  • Fantôme : de quoi s'agit-il ?

    Voir la réponse

    Doublure qu'on passe pour remplir un paramètre obligatoire, et que le test n'utilise jamais.

    Un constructeur qui exige un service qu'un test n'appelle pas reçoit un fantôme (null ou une doublure vide) : il ne sert qu'à faire compiler.

  • Chaque refactoring casse une trentaine de tests, alors que le comportement de l'application ne change pas. Ces tests vérifient avec verify l'ordre et le nombre de chaque appel interne. Quelle est la cause ?

    • Ils figent la manière de faire, pas le résultat observable
    • Les simulacres sont plus lents que les bouchons et déclenchent des échecs au hasard
    • Mockito est incompatible avec les refactorings et demande une version plus récente
    • Il manque des tests de bout en bout qui amortiraient les changements internes
    Voir la réponse

    Ils figent la manière de faire, pas le résultat observable

    Un simulacre qui contrôle chaque appel interne lie le test à la structure du code. Refactorer change cette structure sans changer le comportement, et le test casse quand même. On ne vérifie par verify que les échanges visibles de l'extérieur (un mail envoyé).

Réviser ce deck