Pensez-vous que des objets moqueurs dans le test Junit sont un meilleur pratique? Je ne vois pas le gros avantage. Bien sûr, si vous avez une base de données qui ne doit pas être prise en compte dans votre test, cela est logique, mais pourquoi ne vient pas d'injecter une autre implémentation de ce composant (si le ressort est utilisé). Une usine d'objet pour les tests rendrait cela beaucoup plus facile. Je n'ai pas beaucoup d'expérience (nous utilisons Mockito), mais j'ai déjà vu que le code d'application est modifié de sorte que certaines propriétés se moquent! Les cas de test ne devraient jamais efforcer de tels changements de code productif dans mon adpinion.
Alors, que pensez-vous de ce sujet? Dans quels cas vous moquez-vous de votre objet ou pourquoi vous ne le faites pas?
4 Réponses :
L'idée de moquer est que vous isolez totalement la chose que vous testez. Ensuite, lorsque le test échoue, vous pouvez être sûr où le problème est sans avoir à chasser à travers l'arbre de dépendance de la classe entière. Si vous testez le comportement de plusieurs classes ensemble, ce n'est pas vraiment des tests unitaires.
Une usine d'objet pour les tests faciliterait probablement des objets avec Méthodes Stubbed et le Mocking Les cadres sont essentiellement des usines d'objet génériques pour une utilisation dans des tests. Mais se moque de plus que des gouffers font une différence que Martin Fowler passe en détail ici: http: // martinfowler.com/articles/mocksarentstuts.html .
Si vous trouvez de la maquette ardue, et vous constatez également que vous en faites beaucoup, c'est un exemple classique de TDD qui vous indique que votre conception pourrait être améliorée.
J'ai déjà vu cette application le code est modifié de sorte que certains Les propriétés se moquent! Cas de test ne devrait jamais efforcer de tels changements dans Code productif dans mon adpinion.
L'idée de base de TDD est que, en vous obligeant à faire appel à tout votre code, la conception en général deviendra mieux. Cela ne signifie pas nécessairement que tout ce qui est moqueur, cela pourrait également signifier réduire le couplage de sorte que moins moqueur soit nécessaire.
Même si vous n'êtes pas d'accord avec cette philosophie (je ne l'achète pas à 100% moi-même), tant que vous croyez que les tests automatisés fournissent une valeur, modifiez le code de production pour supporter cette valeur (sauf si sérieusement compromet la conception d'une autre manière).
réduit les dépendances
L'objet de valeur ne doit pas être moqué
Je pense que la vraie question est de savoir si l'unité est une meilleure pratique ou non. Si vous croyez que c'est, alors l'utilisation de moqueurs est une nécessité, du point de vue d'une unité testée isolée de la mise en œuvre de ses dépendances.
Il y a une certaine confusion dans la manière dont cela se rapporte au concept de Testability , cependant. Le code compliqué et convoluté n'est pas essentiel essentiellement parce qu'il est difficile de comprendre. Code bien facturé qui a une conception propre et simple est généralement plus facile à comprendre et à entretenir; Pourquoi devrait-il être difficile à tester unitaire, alors?
La confusion découle de certaines limitations arbitraires présentes dans certains outils moqueurs, tels que l'incapacité de simuler final ou statique ou la nécessité d'avoir l'unité testée directement. Utilisez Mock Objects créé dans le code de test. D'autres outils moqueurs n'ont pas ces limitations et ne nécessitent donc pas que "le code d'application soit modifié de manière à ce que certaines propriétés soient moquables". Avec les langages de programmation modernes / plates-formes (Java, C #, Python, Ruby, etc.) tout est moqueur; C'est juste une question d'exposition de ce pouvoir dans une API moqueuse et a déjà été fait pour chacune de ces langues (dans l'intérêt de la divulgation complète, je développe un tel outil).