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.

Ça indique que la dépendance mockée est soit trop complexe (ex. trop de responsabilités), soit qu'elle a une faible cohésion.

Un mock doit utiliser des arguments précis lorsque le comportement testé 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 ne doit être utilisée que 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éé 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.

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.

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ées 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-être 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.

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 tests 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 isoler correctement dans votre design!

Voir "Mock only types that you own" dans GOOS.