Wie testet man diese IoC-Registrierung mit benannten Komponenten? (Autofac)

Question

Ich bin dabei, einige unserer komplexen Erstellungscode zu konvertieren, um einen IoC-Container, Autofac, zu verwenden, und weil ich ein großer Gläubiger in TDD bin, schreibe ich Komponententests für die Modulkonfiguration.

Der Großteil der Funktionalität ist sehr einfach zu testen, z.B.

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

Aber wir haben eine Reihe von Fällen, in denen wir mehrere Implementierer von der gleichen Schnittstelle und verschiedene Implementierer haben auf unterschiedliche konkrete Klassen weitergegeben werden. Ich habe das gelöst, indem ich die benannte Registrierung z.

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

Was ich kann nicht herausfinden ist eine einfache Möglichkeit, ein Gerät zu testen, um sicherzustellen, dass Foo bekommen ThingImplementer und nicht OtherImplementer zu schreiben. Ich frage mich, ob es die Mühe wert ist, wir haben Integrationstests auf hoher Ebene, die das abdecken, aber sie geben nicht die Dokumentation oder den Refactoring-Nutzen, die Komponententests tun.

Würden Sie einen Komponententest dafür schreiben? Wenn ja, wie?

Answer 1

Sie würde in der Regel nicht testen Sie die Konfiguration des Containers in Ihren Unit-Tests. In Ihrer Komponententestumgebung verwenden Sie keinen Container, um Abhängigkeiten zu injizieren (Sie tun dies von Hand), und wenn Sie dies tun würden, würden Sie gefälschte Objekte und nicht die realen/Produktionstypen injizieren. Daher ist die Containerkonfiguration Ihren Komponententests normalerweise nicht bekannt.

Ich teste manchmal, ob der Container die Stammtypen der Anwendung erstellen kann (z. B. die Controller-Klassen einer MVC-Anwendung oder die Page-Klassen einer WebForms-Anwendung). Da der Container ein Diagramm von Objekten instanziiert, gibt es mir eine gute Idee, ob der Container richtig konfiguriert ist. Ich bin jedoch nie interessiert, ob der Container die korrekte Implementierung zurückgibt. Meistens gibt es sogar nur eine Implementierung einer registrierten Schnittstelle, die für den Anwendungsstamm zugänglich ist, so dass es kaum schief gehen kann.

Wenn Sie Ihren Container Konfiguration testen möchten, ist es vielleicht zu komplex und Sie sollten versuchen, Ihre Anwendung Design zu vereinfachen, so dass Sie die Registrierung vereinfachen kann.

Answer 2

Nichts Neues hier, nur Erweiterungen von Steven Punkte.

Wie Steven sagt, das ist definitiv kein Unit Test. Sie könnten es vielleicht als Lerntest betrachten. Schauen Sie sich die Ninject-Testsuite an - sie zeigt, wie sie solche Tests durchführen (aber denken Sie daran, dass sie einen Container schreiben). Ich nehme an, Autofac hat ähnliche Tests.

gesagt haben, dass, wenn Sie es spüren ist interessant, Verhalten und es wird nicht schuppig, ist es nicht in eine Integration Suite bleiben schaden.

Der andere Punkt in Bezug auf die Tatsache, dass es extern ist, ist auch sehr gültig - siehe den Begriff einer Onion Architecture