"10 Blick über den Tellerrand (S. 287-288)

10.1 Testen von EJBs

Ein Aspekt, der beim Einsatz einer Technologie wie EJB nicht außen vor bleiben darf, ist die Frage nach der Testbarkeit. Neben der Zeit, die für die Erstellung von neuem Code aufgewendet wird, muss auch die Zeit, die für die testweise Ausführung benötigt wird, ins Kalkül einbezogen werden, will man die Effizienz einer Technologie bewerten. Denn was hilft das einfachste Programmiermodell, wenn die eingesparte Zeit wegen zu komplizierter Testbedingungen wieder verloren geht. Vor diesem Hintergrund war ein Ziel, das sich das EJB-Spezifikationsteam mit dem neuen Standard auf die Fahnen geschrieben hat, das Thema Testbarkeit. Mit den bisherigen Standards war eine testgetriebene Entwicklung nur sehr schwer möglich.

Aufgrund zeitraubender Build/Deploy-Zyklen gestaltete sich das Testen von EJBs innerhalb eines Application-Servers ausgesprochen mühsam. Außerhalb des Servers war es meist nur sehr eingeschränkt möglich, da die Beans eine Menge an programmatisch angesprochenen Serverdiensten benötigten – allen voran den Namensdienst. Welche Möglichkeiten EJB3 im Hinblick auf das Thema Testen zu bieten hat, was dabei dem Entwickler eine Hilfestellung bietet und was noch an Stolpersteinen im Weg liegt, soll nun betrachtet werden.

10.1.1 Warum Testen?

Die bereits angesprochene schwere Testbarkeit von EJBs nach altem Standard hat dazu geführt, dass dieses wichtige Thema im Bereich der Entwicklung von EJB-basierten Systemen in der Vergangenheit oft sehr stiefmütterlich behandelt wurde. Der damit verbundene Aufwand war den Projektverantwortlichen häufig ein Dorn im Auge, und Aussagen wie „Wir haben keine Zeit zum Testen“ oder „Während wir testen, können wir keine neuen Features implementieren“ waren leider an der Tagesordnung.

Nun sind aber Entwickler auch Menschen, denen bekanntlich Fehler unterlaufen. Das ist so weit kein Problem, solange man sich dieser Tatsache bewusst ist und versucht, diese Fehler zu entdecken und zu beseitigen, falls sie sich eingeschlichen haben. Hierbei gilt: Je früher ein Fehler entdeckt wird, umso leichter ist er meist zu beseitigen, wobei sich seine negativen Auswirkungen minimieren. Aus diesem Grund sollte der Test einer Software so früh wie möglich einsetzen.

Die Integration der einzelnen Teile einer Anwendung oder gar deren Abnahme sind als Zeitpunkte deutlich zu spät. Natürlich müssen auch hier Tests stattfinden. Während der Integration wird das Zusammenspiel der einzelnen Teile geprüft (im so genannten Integrationstest), und während der Abnahme muss natürlich das fachlich korrekte Verhalten der Anwendung nachgewiesen werden (über so genannte fachliche Abnahmetests).

Das Testen sollten aber schon viel früher, bereits bei der Entwicklung der einzelnen Bestandteile (englisch: Units), einsetzen. Die hierfür zuständige Variante von Tests wird als Unit-Test bezeichnet. Unit-Tests sind automatisierte Tests, die in Form von Testklassen neben den eigentlichen Anwendungsklassen bereitgestellt werden. Hierbei wird oft eine 1:1-Beziehung zwischen Anwendungsklasse und Testklasse empfohlen, d.h. eine Testklasse ist für eine Anwendungsklasse zuständig."