In unserem Projekt verwenden wir einen Cache zum Vorhalten von oft benutzten Daten, u.a. für Länder und Bundesländer. Für die Übersetzungen derselben in viele Sprachen habe ich einfach je eine einfache Tabelle angelegt mit einer Referenz auf das jeweilige (Bundes-)Land, dem Sprachen-Isocode und dem Namen in der entsprechenden Sprache. Per NHibernate-Mapping dann die Übersetzungen als <bag> an das (Bundes-)Land angeheftet - fertig.
Beim NUnit-Testen bekam ich nach dem Einbau der Übersetzungen beim Update von (Bundes-)Ländern allerdings diesen Fehler:
NHibernate.HibernateException: Illegal attempt to associate a collection with two open sessions.
Offensichtlich waren die neuen Collections an den Domainobjekten Schuld. Was war passiert? Beim Aufrufen der Frontend-Seiten kam dieser Fehler nicht...
Nun, die Exception gibt uns einen guten Tipp: Wir haben zwei offene Session, mit denen die Collection von Übersetzungen assoziiert werden soll. Aber warum nur in den Tests und warum dort überhaupt?
Eine erste Erklärung: Im Frontend benutzen wir für die NHibernate-Sessions das One-Session-Per-Request-Pattern, so dass alle Manipulationen an den Session-Objekten (inkl. Update) innerhalb derselben Session passieren. Außerdem funktionierte dort das Dispose der Session zuverlässig. In unseren Tests war das ja leider nicht der Fall, so dass wir also irgendwie eine geöffnete Session nicht schließen. Durch die Benutzung eines Caches kamen wir in die Verlegenheit, Länderobjekte in einem Testcase in den Cache zu schreiben und diese in einem folgenden Testcase wiederzuverwenden. Als an dieser zweiten Stelle ein Update passieren sollte, knallte es, denn das Objekt im Cache hielt eine Referenz auf NHibernate-Collection, die noch mit einer vergangenen Session assoziiert war. Beim Update versucht NHibernate aber, dieselbe Collection an die aktuelle Session zu binden, was eine Exception wirft.
Der Cache war also Schuld. Oder zumindest war das mein erster Gedanke. Und tatsächlich: Wenn ich im [SetUp] der NUnit-TestFixture ein Cache.Clear() aufrufe, verschwindet der Fehler! Keine Überraschung, denn jetzt benutzen wir ja keine Objekte aus "alten" Sessions mehr. Aber Moment mal, im Frontend benutzen wir doch denselben Cache?! Und da gibt es diesen Fehler nicht.
Nach ein wenig Haareraufen, kam ich dann zurück zu der Feststellung, dass es ja ein Problem mit einer offenen Session gab. Also setzte ich da nochmal an.
Für das Lifecycle-Management unserer Serviceklassen benutzen einen Autofac-IoC-Container. Dieser stellt auch die NHibernat-Session bereit. Zum Benutzen der Services haben wir eine ServiceLocator-Klasse, die uns die vom Container generierten Serviceinstanzen auf Anfrage zurückgibt. Um diese Architektur in den NUnit-Tests zu nutzen, schrieben wir flugs eine Basisklasse BaseTest, von der alle Testklassen ableiten und fortan Zugriff auf alle Services haben. Das Lifecycle-Management des Containers wird dort ebenfalls verwaltet.
public BaseTest()
{
InitializeContainer();
}
~BaseTest()
{
DisposeContainer();
}
Wie sich nun herausstellt, eine dumme Idee! Beim Debuggen stellte ich fest, dass der Konstruktor zwar von jeder TestFixture (also jeder Testklasse, die selbst mehrere Tests enthält) in Reihenfolge aufgerufen wird, dass aber der Destruktor einer Testklasse keineswegs zuverlässig vor dem Konstruktor der nächsten Testklasse ausgeführt wird! Damit wird der Container der ersten Testklasse nicht Dispose'd und in Folge die NHibernate-Session nicht geschlossen, so dass wir den o.g. Fehler bekommen.
Wahrscheinlich ist das Ausführen von Businesslogik in einem NUnit-TestFixture-Konstruktor bzw. viel schlimmer im Destruktor ein absolutes NoNo. Dafür gibt es schließlich die Attribute [TestFixtureSetUp] und [TestFixtureTearDown]. Mit dem folgenden Code funktioniert denn auch alles wie gewollt:
[TestFixtureSetUp]
public virtual void TestFixtureSetUp()
{
InitializeContainer();
}
[TestFixtureTearDown]
public virtual void TestFixtureTearDown()
{
DisposeContainer();
}
Ein kleiner Wehrmutstropfen bei dieser Lösung ist, dass man beim Testklassen-Schreiben jetzt daran denken muss, diese Methoden zu überschreiben, wenn man weitere Funktionalität in [TestFixtureSetUp] und/oder [TestFixtureTearDown] benötigt...
Alles Gute, Oliver