Laden...

Vorgangsweise für Integrationtests + Verwendung von DI container?

Erstellt von HannesB vor 13 Jahren Letzter Beitrag vor 13 Jahren 1.116 Views
HannesB Themenstarter:in
185 Beiträge seit 2005
vor 13 Jahren
Vorgangsweise für Integrationtests + Verwendung von DI container?

hallo,

ich möchte euch gerne zu eurer Vorgangsweise bzw. was ihr mir zu folgendem Problem empfehlen würdet fragen:

Um nHibernate Mappings zu testen + dass es für jede Entität möglich ist, CRUD Operationen auszuführen, gibt es Integrationtets.
Diese haben folgenden Aufbau:

  • nHibernate Session erstellen
  • Save, Get, Delete ausführen
    ...also recht einfach 😉

Innerhalb der Session Klasse (welche die nHibernate Session kapselt) wird eine weitere Klasse erstellt - der Zugriff auf einen Volltextindexserver.
Bisher war dies direkt via "new IndexingServer();"

Das habe ich nun geändert - die Abhängigkeit wird vom DI container (Castle Windsor) geladen: Registry.Container.Get<IIndexServer>();

Dadurch ergibt sich nun das Problem, dass vor ALLEN Tests, welche die Session Klasse verwenden, der DI Container entsprechend aufgesetzt werden müsste d.h. einen Implementierung für "IIndexServer" registriert werden müsste.

Hier könnte ich nun z.B. Alle Testklassen für die "Datenbank Integrationtests" von einer gemeinsamen Base ableiten und dort im [TestFixtureSetUp] die benötigte(n) Implementierung registrieren.

Ist das aber die empfohlene Vorgangsweise?
Zuvor hatten viele Klassen die benötigten Komponenten teilweise im .ctor übergeben bekommen bzw. selbst via "new" erzeugt.
Das "selbst erzeugen" möchte ich natürlich vermeiden - hier sollen die Instanzen vom DI Container kommen, nur verursacht das leider gewisse Voraussetzungen bei der Ausführung der Integrationtests.

Bei den Unittests habe ich es so geändert, dass für die benötigten Komponenten Mocks im DI Container registriert werden + das funktioniert wie erwartet. 👍
Nun würde ich es auch bei den Integratointests entsprechend ändern, möchte DAVOR jedoch fragen, ob das überhaupt die empfohlene bzw. auch von euch angewandte Vorgangsweise ist?

Vielen Dank (fürs lesen des langen Postings 😉 + für eure Unterstützung vorab,
Hannes

Nachtrag: Derzeit habe ich es mal gem. dieser Vorgangsweise "umgebaut": Design Patterns: Teil 2 – Dependency Injection mit Castle Windsor

Das geht, weil jeder "Datenbank Integrationtest" beim Einstieg eine Methode "DatabaseTest.For" aufruft, wo ich den DI-Container initialisieren kann.
Ob diese Vorgangsweise "best practice" ist, weiß ich nicht.

fg
hannes

5.742 Beiträge seit 2007
vor 13 Jahren

Hier könnte ich nun z.B. Alle Testklassen für die "Datenbank Integrationtests" von einer gemeinsamen Base ableiten und dort im [TestFixtureSetUp] die benötigte(n) Implementierung registrieren.

Ob es empfohlen ist oder nicht - ich würde es so machen 😉

Allerdins weiß ich nicht, ob MSTest mit dem Ableiten klarkommt - bei NUnit ist das auf jeden Fall der Fall.

Meistens Stelle ich in meinen Testklassen eine Methode Create bereit, die das jeweilige Objekt erzeugt und die benötigten Informationen aus Feldern liest. Das hat den Vorteil, dass man die Parameter zur Erzeugubg relativ leicht pro Test ändern kann.

S
443 Beiträge seit 2008
vor 13 Jahren

Ich glaube da gibt es 2 passende Möglichkeiten,
einerseits im Rahmen eines Unittest übergibt man im ctor das eine benötigte Interface als Mock, dann wäre es ein "sauberer" Unittest.

Andererseits machst Du ja Integrationtests, also Tests mit lebenden Daten für das würdest Du aber auch einen "lebenden" IIndexServer benötigen welchen Du dir über IoC holst.

Bei genauerem Überlegen würde ich mit dem Argument, wenn schon IntegrationTest dann richtig, die zweite Variante empfehlen.

Gehen tut aber beides.

mbg
Rossegger Robert
mehr fragen mehr wissen

Montag morgen ist die beste Zeit um eine erfolgreiche Woche zu beginnen

HannesB Themenstarter:in
185 Beiträge seit 2005
vor 13 Jahren

Danke für eure Antworten,

ich habe es inzwischen so abgeändert: Design Patterns: Teil 2 – Dependency Injection mit Castle Windsor

Das ist möglich, weil ich bei den "Datenbank Integrationtests" beim Starten eine Methode "DatabaseTest.For" aufgerufen wird, wo ich den DI-Container initialisieren kann + funktionieren.

Fürs Testen verwende ich nUnit + ja es sind Integrationtests, möchte daher kein Fake-Objekt injecten, wo diese "mit den DB Tests zu tun haben".
Dort wo diese aus dem Container kommen + für den Test nicht relevant sind, verwende ich Fake Objekte.

thx
hannes