Inversion of Control und Dependency Injection im Kontext von EJB 3.0, Teil 3

Umkehr der Beweislast

Oliver Ihns

EJB-Komponenten und ihre Testbarkeit beziehungsweise Nicht-Testbarkeit – ein Thema, welches immer mal wieder als negativer Punkt gegen EJBs herangezogen wird. Dieser dritte Artikel, der sich im Rahmen des EJB Corner mit dem Thema Inversion of Control (IoC) und Dependency Injection (DI) im Kontext von EJB 3.0 beschäftigt, fokussiert die vereinfachte (externe) Testbarkeit von EJB 3.0-Komponenten und liefert Feedback aus der Entwicklergemeinde zu diesem Thema.

Die Möglichkeit, EJB-Komponenten externen qualitätssichernden (Regressions-)Tests, beispielsweise durch Einsatz von Testframeworks wie JUnit [6], zu unterziehen, ist eine seit langem gestellte Forderung an die der EJB-Komponententechnologie zugrunde liegende Architektur. Bis dato war es aufgrund der Mikroarchitektur der EJB-Komponenten und des EJB-Containers, der zur Laufzeit der EJB-Komponenten benötigt wurde, nicht ohne größere Anstrengungen und Tricks möglich, auch EJB-Komponenten Tests zu unterziehen, welche die EJB-Komponenten in ihrer Gesamtheit abdeckt. Cactus [5] oder JUnit in Verbindung mit Mock-Objekten waren bzw. sind Ansätze, die Testbarkeit von EJB-Komponenten doch noch zu erreichen.Wo liegt bei der Testbarkeit oder auch Nicht-Testbarkeit von EJB-Komponenten das Problem? Entgegen einiger Meinungen sind EJB-Komponenten auch in den gegenwärtigen Versionen (hiermit sind die EJB-Versionen kleiner 3.0 gemeint) sehr wohl über Unit-Tests testbar; auch außerhalb eines sie umgebenden EJB-Containers. Die Einschränkung hierbei ist, dass bei dem zuvor beschriebenen Szenario lediglich technische Tests bzw. Tests einzelner Artefakte (z.B. der Bean-Klasse) der Komponenten durchgeführt werden können, nicht jedoch Tests der jeweiligen Komponente als Ganzes.Wie verhält es sich, wenn eine EJB-Komponente transaktional ist? Ist sie auch dann außerhalb eines EJB-Containers testbar? Oder was ist mit dem Fall, wenn eine EJB-Komponente eine andere EJB-Komponente anspricht bzw. benötigt, um einen fachlichen Fall technisch umzusetzen? Diese Fälle sind natürlich klar: Es wird ein EJB-Container bzw. Java EE Application Server benötigt. Denn schließlich sind in diesen Fällen Mechanismen des EJB-Containers (nämlich die Kommunikation mit anderen EJB-Komponenten) und des Java EE Application Server involviert. Diese Tatsache wiederum wird ab und dann als Argument dafür gebracht, dass eben diese Notwendigkeit der Nutzung des EJB-Containers bzw. Java EE Application Server bei Unit-Tests ein handfester Nachteil der EJB-Technologie sei. Dass in zuvor genannten Fällen ein EJB-Container bzw. Java EE Application Server benötigt wird, ist unbestritten. Denn wenn man eine EJB-Komponente in der Gänze ihrer Leistungsfähigkeit bzw. fachlichen Eingebundenheit testen möchte, benötigt man selbstverständlich Dienste (z.B. Transaktions-Handling, Security-Handling, Concurrency-Handling) und andere fachlichen (EJB-)Komponenten, auf die eine EJB-Komponente zugreift.Interessanterweise habe ich nach Vorträgen und auf Podiumsdiskussionen, die ich zum Thema EJB 3.0 gehalten habe, vielfach von Entwicklern der verschiedensten Unternehmen die Aussage erhalten, dass der Punkt der angeblich nicht vorhandenen Testbarkeit gar nicht als ein solches Problem gesehen wird. Zum einen werden EJB-Komponenten bei diesen Unternehmen seit Jahren testgesichert und entsprechend in Tests eingebunden und zum anderen ist der Punkt, dass man einen EJB-Container bzw. Java EE Application Server für ganzheitliche Tests benötigt, in der Realität ebenso wenig ausschlaggebend. Denn EJB-Komponenten verwenden per se Dienste und andere Komponenten und diese leben nun einmal in einem sie umgebenden Java EE Application Server. Auch das gern gebrachte Argument des notwendigen Startens des Java EE Application Server wird in der Realität nicht so kritisch gesehen. Auch hier gibt es in der Mehrheit die Kommentare, dass dies kein Problem sei, denn schließlich dauert das Starten eines Java EE Application Server keine Stunden.Es scheint, dass das Thema der Testbarkeit von EJB-Komponenten in der Praxis erstens nicht so heiß gegessen wird, wie partiell darüber geschrieben oder angemerkt wird, und zweitens in der Praxis ganz pragmatisch angegangen wird.

Geschrieben von
Oliver Ihns
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.