Comment tester unitairement cet enregistrement IoC en utilisant des composants nommés? (Autofac)

Question

Je cherche à convertir une partie de notre code de création complexe pour utiliser un conteneur IoC, Autofac, et parce que je crois énormément en TDD, j'écris des tests unitaires pour la configuration du module.

La plupart des fonctionnalités sont très faciles à tester, par ex.

var obj = container.Resolve<IThing>(); 
Assert.IsInstanceOfType(obj, typeof(ThingImplementer)); 

Mais nous avons un certain nombre de cas où nous avons plusieurs de la implémenteurs même interface et différentes sont transmises implémenteurs à différentes classes concrètes. J'ai résolu ceci en utilisant l'enregistrement nommé par ex.

builder.RegisterType<ThingImplementer>().Named<IThing>("Implementer1"); 
builder.RegisterType<OtherImplementer>().Named<IThing>("Implementer2"); 
builder.Register(c => new Foo(c.ResolveNamed<IThing>("Implementer1"))).As<IFoo>(); 

Ce que je ne peux pas comprendre est un moyen facile d'écrire un test unitaire pour faire en sorte que Foo se ThingImplementer et non OtherImplementer. Je me demande si cela en vaut la peine, nous avons des tests d'intégration de haut niveau qui couvrent cela, mais ils ne fournissent pas la documentation ou les avantages de refactoring que font les tests unitaires.

Souhaitez-vous écrire un test unitaire pour cela? Si oui, comment?

Answer 1

Vous ne testeriez généralement pas la configuration de votre conteneur dans vos tests unitaires. Dans votre environnement de test unitaire, vous n'utilisez pas de conteneur pour injecter des dépendances (vous le faites à la main) et si vous le faites, vous injecterez de faux objets, et non les types réels/de production. Par conséquent, la configuration du conteneur est généralement inconnue pour vos tests unitaires. Ce que j'ai tendance à faire parfois est de tester si le conteneur est capable de créer les types racine de l'application (tels que les classes de contrôleur d'une application MVC ou les classes Page d'une application WebForms). Étant donné que le conteneur va instancier un graphe d'objets, il me donnera une bonne idée si le conteneur est configuré correctement. Cependant, je ne suis jamais intéressé si le conteneur renvoie l'implémentation correcte. La plupart du temps il n'y a même qu'une seule implémentation d'une interface enregistrée qui est accessible pour la racine de l'application, donc ça ne pourrait pas mal tourner.

Si vous voulez tester la configuration de votre conteneur, c'est peut-être trop complexe et vous devriez essayer de simplifier la conception de votre application afin de simplifier l'enregistrement.

Answer 2

Rien de nouveau ici, juste des extensions des points de Steven. Comme le dit Steven, ce n'est certainement pas un test unitaire. Vous pourriez peut-être le voir comme un test d'apprentissage. Jetez un oeil à la suite de tests Ninject - elle montre comment ils font de tels tests (mais rappelez-vous qu'ils écrivent un conteneur). Je suppose qu'autofac a des tests similaires. Cela dit, si vous pensez qu'il y a un comportement intéressant et qu'il ne deviendra pas flou, il n'y a pas de mal à le coller dans une suite d'intégration. L'autre point concernant le fait qu'il est externe est également très valable - voir la notion d'un Onion Architecture