Injection de dépendances, tests unitaires et d'information Hiding [fermé]

Question

Supposons que vous ayez une Foo classe avec un membre privé de type Bar. Vous ne voulez pas que les utilisateurs sachent que la mise en œuvre de Foo contient une barre et que vous ne souhaitez pas que les utilisateurs soient en mesure de créer leur propre bar et de le transmettre par le constructeur de Foo, toute autre méthode, ou un fichier de configuration.

Edit:. Bar est également problématique en ce qu'elle accède à des ressources en dehors du contrôle de votre environnement de test, comme une base de données spéciale, connexion réseau, ou un autre processus

Que faites-vous quand vous voulez aussi être en mesure de Foo test unitaire? Est l'injection de dépendance encore possible? Est-ce que cela signifie Bar et Foo sont trop étroitement couplés (même si la dépendance est une façon) et que cette situation est jamais acceptable un être?

Answer 1

[Disclaimer: Je travaille à Typemock ]

Vous avez trois possibilités:

1. Créer une méthode interne qui définit la classe Bar -. En utilisant InternalVisibleTo dans le fichier assemblyInf.cs vous pouvez activer vos tests pour définir cette classe
2. Utilisez DI pour injecter la classe Bar, au cours du test changer cette classe avec un mannequin ou faux.
3. Utiliser cadre Faking / Mocking comme Typemock Isolateur (.NET) qui vous permettent de définir le comportement faux sur les objets créés dans une autre classe en utilisant Isolate.Swap.NextInstance<Bar>.With(fakeBar);

Answer 2

Vous ne voulez jamais cacher les dépendances si vous pouvez l'aider.

Si c'est votre code, vous devez faire la dépendance explicite en redessinant Bar d'accepter les objets produits par la ressource coûteuse plutôt que l'accès à la ressource coûteuse directement: déplacer le code d'accès de base de données (ou quoi que ce soit) sur Bar et en Foo, où vous pouvez injecter double de test.

Si ce n'est pas pratique (c.-à-vous traitez avec les classes de quelqu'un d'autre), liste de Dror est très bon.

Answer 3

Si le type de bar est juste un détail de mise en œuvre de Foo, vos tests unitaires ne doivent jamais se soucier de la création de bars, car ils ne devraient exercer l'interface publique de Foo de toute façon.

EDIT:. Si la barre accède à des ressources externes alors je rendrais une dépendance explicite pour Foo et nécessitent une instance à passer dans le constructeur de Foo qui pourrait alors être facilement moqué pour les tests unitaires

Answer 4

Votre question n'est pas que vous avez besoin d'accéder à un membre privé. C'est seulement un symptôme du fait que la classe en question n'a pas été conçu pour être isolé . Il ne permet qu'une seule utilisation très spécifique, ce qui est de new un objet qui va à une ressource coûteuse.

Même si vous réussissez à le piratage autour de la conception invérifiable, vous serez encore que de faire des tests d'intégration. Les tests unitaires sont sur l'isolement, qui est à l'opposé de l'intégration. Étant donné que cette classe ne peut pas être isolé, par définition, vous ne pouvez pas l'unité tester.

Y at-il une raison pour laquelle externalisant la dépendance est indésirable? Qu'en est-il cet objet d'être exempte de dépendance à injection comme une autre?

Modifier :

Je me rends compte bien sûr que vous peut l'isoler avec une supercherie. Cependant, ces techniques contournent les interfaces publiques, ce qui limite la flexibilité future et d'accroître la probabilité que quelqu'un va le casser (essentiellement, réduire à néant l'utilité des députés).