Temps estimé: 15 minutes
Exercices : odeurs et Mocks
En développement de logiciel, une "odeur" (dans le code) est un symptôme de mauvaise architecture ou de code non optimisé. À force de pratiquer, on apprend à reconnaître ces situations plus facilement et comment les réparer.
Voici quelques questions sur les mocks et les "odeurs":
Question 1
Quelles conclusions pouvons-nous tirer d'une classe de test qui contient une quantité excessive de mocks?
C'est un indicateur que la classe testée détient beaucoup de dépendances. C'est souvent dû à un couplage excessif qui complique la maintenance du système.
Question 2
Quelles conclusions pouvons-nous tirer lorsqu'il est impossible de créer un mock sans surcharger une quantité excessive de ses comportements.
Ça indique que la dépendance mockée est soit trop complexe (ex. trop de responsabilitées) ou qu'elle a une faible cohésion.
Question 3
Quand est-ce qu'un mock doit utiliser des arguments précis versus des any()?
Un mock doit utiliser des arguments précis lorsque le comportement tester dépend des arguments envoyés (ex. lorsqu'un appel avec arguments est fait à une dépendance pour déléguer une tâche).
L'utilisation d'any() évite de rendre un test inutilement fragile et doit seulement être utilisé lorsque l'argument passé n'est pas important. Voici quelques exemples:
- Lorsque l'argument est déjà testé dans un autre test.
- Lorsqu'un mock est créer seulement dans le but d'envoyer une réponse précise.
- Pour s'assurer qu'un appel ne doit PAS être fait, car on cherche l’absence d’appel peu importe les valeurs de paramètres.
Question 4
Quelles conclusions pouvons-nous tirer si nous devons modifier la classe que nous testons afin de réussir à injecter notre mock?
Si vous avez de la difficulté à injecter une dépendance lors de vos tests, imaginez comment d'éventuels utilisateurs de la classe vont se sentir :) Le test vous force à être en position d'utilisateur, il ne faut donc pas blâmer le framework de test/mock, mais bien vous en servir comme opportunité d'améliorer votre design!
Typiquement, c'est qu'une classe fait un new au milieu d'une méthode et "soude" la dépendance. Il serait
mieux d'injecter celle-ci dans le constructeur afin que tous puissent modifier la dépendance au besoin.
Question 5
Quelles conclusions pouvons-nous tirer si, en cherchant un problème sur google, on trouve que la solution est d'utiliser powermock ?
Généralement, c'est que vous essayez de mocker une méthode static. La solution a davantage rapport
à votre design OO: souvent les méthodes statiques sont causée par un design peu OO. Il y a des
cas pour faire cela, mais en OO ils sont assez rares pour la majorité des types d'application. Si le contexte
en demande beaucoup, peut-etre que l'OO n'est pas le bon choix de paradigme.
Nous verrons au cours de la session des bonnes raisons de faire des méthodes static et comment
les tester correctement, sans un outil surpuissant tel que powermock.
Question 6
J'utilise une librairie/framework, et je ne suis pas capable de faire un mock de la classe que j'utilise.
La réponse courte est "on ne mock jamais le framework". Ceci inclut les librairies ou les utilitaires du langage lorsque nous faisons un test unitaire.
La raison est simple: votre classe est fortement couplée à celle d'une librairie, et ceci devrait être prévu ainsi dans votre architecture. Il y a même des classes pour lesquelles vous ne réussiriez pas à faire de test unitaires (les ORM, entre autres). Nous verrons plus tard dans la session comment gérer ces cas, mais pour l'instant assurez-vous de les isolé correctement dans votre design!
Voir "Mock only types that you own" dans GOOS.