Où prenez-vous des moqueries - des dépendances immédiates, ou augmentez-vous les limites ...?

Question

Donc, je suis relativement nouveau pour les tests unitaires et les moqueurs en C# et .NET; J'utilise xUnit.net et Rhino Mocks respectivement. Je suis un converti, et je me concentre sur l'écriture des spécifications de comportement, je suppose, au lieu d'être purement TDD. Bah, sémantique; Je veux essentiellement un filet de sécurité automatisé. Une pensée m'a frappé cependant. Je reçois la programmation contre les interfaces, et les avantages en matière de séparation des dépendances vont là. Vendu. Cependant, dans ma suite de vérification de comportement (aka tests unitaires ;-)), j'affirme le comportement d'une interface à la fois. Comme dans, une implémentation d'une interface à la fois, avec toutes ses dépendances moquées et les attentes mises en place. L'approche semble être que si nous vérifions qu'une classe se comporte comme elle le devrait contre ses dépendances collaboratives, et dépend à son tour de chacune de ces dépendances collaboratives pour avoir signé ce même contrat de qualité, nous sommes dorés. Semble assez raisonnable.

Retour à la pensée, cependant. Y a-t-il une valeur dans les tests de semi-intégration, où un test-fixture affirme une unité d'implémentations concrètes câblées ensemble, et nous testons son comportement interne contre les dépendances simulées? Je viens de relire cela et je pense que je pourrais probablement l'avoir mieux formulé. Évidemment, il y aura une certaine quantité de «bien, si cela ajoute de la valeur pour vous, continuez à le faire», je suppose - mais quelqu'un d'autre a-t-il pensé à le faire et en a retiré les avantages?

Answer 1

Votre question a été débattue pendant des années et peut également être reformulée comme "qu'est-ce qu'une unité"?

Il n'existe aucune loi sur les tests unitaires qui stipule que vous devez tester chaque classe isolément. Cependant, pour être maintenable, vous voulez vraiment que les tests ne changent que lorsque le comportement qu'ils testent change. Vu de cette façon, il est souvent raisonnable d'utiliser des versions concrètes de proches collaborateurs et de faux pour des versions plus lointaines.

Le seul endroit où j'utilise absolument des faux d'une sorte ou d'une autre est de suivre Michael Feather Rules of Unit Testing.

Answer 2

Je ne vois pas de valeur dans les tests d'intégration qui ne font que lier ensemble des classes internes entièrement testables unitaires.

Il me semble que la valeur dans les tests d'intégration est là où elle touche la plate-forme ou les interfaces externes, c'est-à-dire les contrats que vous ne pouvez pas tester à l'unité.