Pourquoi y a-t-il tant de halés sur "la moqueur partielle" et le code qui l'exige?
Voici un exemple (théorique) Mise en œuvre: p>
public ComplexResult1 operationA(Stimulus a) {
{
...
result = ...;
}
auditTheChange(a);
}
public ComplexResult2 operationB(Stimulus b) {
{
...
result = ...;
}
auditTheChange(b);
return result;
}
void auditTheChange(Stimulus stim) {
// do a bunch of stuff to record the change
// and interact with another outside service
}
3 Réponses :
Si l'audit est vraiment une fonction interne de la classe, le code doit être testé dans le test de l'unité. Pourquoi votre classe gère-t-elle les opérations et l'audit complexes? L'audit peut-il être déplacé vers une classe distincte?
Si tel est le cas, introduisez l'audit en tant que collaborateur avec cette classe et que vous vous moquez. Sinon, l'unité testez-la.
Vous pouvez utiliser des simulacres partiels, mais dans ce cas, je pense que c'est une indication que la classe fait trop.
Un cas d'utilisation valide pourrait être si toutes les méthodes publiques appellent une sorte de nettoyage () à la fin d'entre eux. Dans ce cas, vous pouvez écrire un test d'unité pour le nettoyage (), lui-même. Ensuite, lorsque vous testez toutes les méthodes publiques, utilisez une simule partielle pour simplement vérifier que le nettoyage () a été appelé évitant de vérifier les détails de ce que le nettoyage () a fait dans chaque méthode publique.
Le point clé est "Qu'est-ce que l'unité testée".
Beaucoup de développeurs pensent OO. Dans OO, "Objet" est l'unité de logiciel de sorte que l'objet soit également l'unité testée dans le test de l'unité. Dans votre exemple, Auditthechange () est une méthode privée dans un objet. Un test d'unité doit uniquement se concentrer sur le comportement de la méthode publique uniquement. Mocker une méthode privée désigne l'étui de test d'unité traitant de certains détails de mise en œuvre de l'unité qui est considérée comme une "odeur de code".
Certains développeurs pensent que l'unité de logiciel est "méthode". Dans votre exemple, vous pensez de cette façon. Étant donné que OperaA et OperationB sont trop compliqués, de sorte que vous créez AuditThechange de manière à ce que la complexité de l'unité opérationnelle et de l'opération soit réduite. Si vous pensez de cette manière, une moqueuse partielle n'est pas une "odeur de code" car la méthode est une unité testée et se moquer d'une méthode privée signifie également "Concentrez-vous sur le comportement, pas les détails de la mise en œuvre".
Il n'y a pas de droit absolu ou faux ici. Cela dépend vraiment de la nature de votre projet ou de votre équipe. J'ai travaillé pour une entreprise développant un système d'information d'entreprise utilisant le ressort. Au printemps, presque toutes les logiques commerciales sont implémentées dans des objets XXXService. Lorsqu'une méthode est trop compliquée, nous déplacons simplement une certaine logique à une méthode privée comme vous l'avez fait dans votre exemple. Si nous déplacons toujours cette logique à une nouvelle classe, il y aura beaucoup de cours et d'objets seront créés et rendront les programmes difficiles à maintenir. Nous venons donc de déplacer la logique sur des méthodes privées et d'utiliser des simulacres partiels. En fait, beaucoup de gens ont besoin de simulacres partiels. Vous pouvez vérifier cette Mockito < / a> document. Au début, Mockito pense que la simulation partielle est une odeur de code. Après une longue discussion et un débat, ils soutiennent également des simulacres partiels maintenant.
Si et juste en général: Ne pas tester les méthodes privées . auditthechange est une fonction privée, vous n'écrivez tout simplement pas un test qui vérifie son invocation.
Vous ne voulez pas que votre test de l'unité soit étroitement couplé à une implémentation.
@Natfar La question était si partielmock est une odeur de code. C'est un lorsque vous n'êtes pas en mesure de tester quelque chose que vous avez l'intention de tester. Mais au cas où vous êtes sûr que votre conception de classes est bien et que vous utilisez partiellement, il est probablement probablement un signe que vous essayez de tester quelque chose dont vous n'avez pas besoin.
Qui est celui qui fait des déclarations de couverture contre toute utilisation de simulacres partielles?
C'est une utilisation assez injustifiée du mot "haïr"
@kirk, de l'EasyMock Documentation: "Dans ce cas, la première chose à faire est d'envisager une refactoring depuis la plupart du temps de ce problème causé par un mauvais design. Si ce n'est pas le cas ou si vous ne pouvez pas faire autrement à cause de Quelques contraintes de développement, voici la solution. "