Q-MOCK : Questions sur les mocks

Questions variées

Mockito

Q1: À quel moment devons-nous utiliser des arguments précis versus des any()?

Architecture et Mocks

Q2: Expliquez le lien entre les Mocks, les interfaces et les abstractions.

Q3: Pourquoi est-ce que de faire un Mock d’une classe concrète peut être le signe d’un problème de design?

Q4: Comment peut-on utiliser les Mocks pour aider à définir une interface?

Architecture et tests unitaires

Q5: Expliquer le lien entre l’architecture logicielle et les tests unitaires

Mocks

Q6: Expliquez clairement le raisonnement derrière la maxime suivante: “Pas assez de Mocks —> Tests unitaires fragiles”. Pourquoi?

Q7: Expliquez clairement le raisonnement derrière la maxime suivante: “Trop de Mocks —> Tests unitaires fragiles”. Pourquoi?

Q8: Comment faire alors pour déterminer si l’on doit mettre ou non un Mock?

Solutions

R1

Nous devrions utiliser des arguments précis lorsque le comportement que nous cherchons à tester dépend des arguments qui sont envoyés. Par exemple, si notre test consiste à s’assurer qu’un appel est correctement fait à un autre composant pour déléguer une tâche, les arguments enovyés sont probablement très importants.

Si toutefois, nous cherchons à instrumenter un mock afin qu’il renvoit une réponse précise, il ne sera pas nécessaire de précier les arguments qu’il devra recevoir.

Parfois, certaines valeurs précises des arguments ont déjà été testés dans un autre test. Nous utilisons alors any afin d’éviter de rendre le test inutilement fragile car la valeur précise n’apporte pas de confiance supplémentaire.

Quand la vérification est qu’un appel ne doit PAS être fait, alors il est préférable de mettre any dans la majorité des cas car on chercher l’absence d’appel peu importe les valeurs de paramètres.

R2

Discutez de vos réponses avec vos collègues.

Pistes: fragilité, contrats, stabilité et cycle de vie.

R3

Voir le chapitre “20. Listening to the Tests”, section “Mocking Concrete Classes” dans Growing Object-Oriented Software Guided by Tests. Disponible via en ligne via la bibliothèque.

R5

Écouter Startup Lab workshop: Test-Driven Design