Testbarkeit – Umkehr der Sinnhaftigkeit?

Ich bin kürzlich (aus gegebenem Anlass) über ein, zugegeben recht altes (04.2006), “Online Artikel” von Oliver Ihns gestolpert: Umkehr der Beweislast

Da die Java EE Version 5 Spezifikation und Produkte langsam den Weg zu der einen oder anderen IT Abteilung schafft, und zur Zeit bei verschiedenen Projekten als mögliche Technologie in Frage kommt, stellt sich immer wieder die Frage nach der Testbarkeit der neuen EJB Spezifikation. Aus diesem Grund habe ich Olivers Artikel durchgelesen und habe mich über die eine oder andere Stelle des Artikels sehr stark gewundert…

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.
(…)

Aha. Wenn ich als Softwarearchitekt eine Architekur ausgewählt habe, die das Testen erschwert, stelle ich dann die Notwendigkeit und Sinnhaftigkeit von testen in Frage. Verständlich.

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.

Bei einem Programmiermodell, dass die Logik sehr eng mit der Infrastruktur vermengt (EJB ist nunmal ein sehr stark invasives Framework, egal ob mit oder ohne Annotationen) stelle ich mir die Frage, wie sinnvoll Tests einzelner Artefakte (teilweise lediglich abstrakte Klassen und Interfaces) sind. Seltsamerweise wird an dieser Stelle kein Designfehler des Frameworks vermutet, sondern die Sinnhaftigkeit von Tests.

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.

Nein, keine Stunden. Minuten. In der Summe Stunden. Je mehr minuten, desto seltener werde ich Testdurchläufe starten. Desto weniger Testdurchläufe, um so weniger werde ich mich dazu motivieren können, Tests zu schreiben (wozu auch, dann wirds noch länger dauern). Das erschwert Refactoring, wiederum werden dadurch Architektur- und Designkorrekturen erschwert. Da kann schon mal die Qualität der Software auf der Strecke bleiben.

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.

Was ist mit “pragmatisch angegangen” gemeint? Wir klicken uns durch die Anwendung? Wir verzichten auf automatisierte Builds?

Mit EJB 3.0 werden die Möglichkeiten zum Testen von EJB-Komponenten gegenüber den Vorgängerversionen sicherlich um einiges verbessert.
(…)
… was wiederum bedeutet, dass in diesen Fällen der Java EE Application Server bzw. EJB-Container auch weiterhin für die Tests benötigt wird.

Sicher? Benötige ich nicht immer noch den Application server, wenn ich meine Beans testen möchte? Wie leichtgewichtig ist die Testumgebung die ich konfigurieren und starten muss, um meine Komponenten zu starten?

Ich verstehe Tests so, das Sie nur dann Sinnvoll sind, wenn sie mir nicht nur sagen, ob das System funktioniert (was ja eh nicht geht, sie können mir nur zeigen, ob die Tests die ich geschrieben habe funktionieren), sondern auch in der Lage sind zu zeigen, welche Komponente gerade für das Fehlverhalten zuständig ist. Es ist sehr schön wenn alle Tests grün sind – was bedeuten aber rote Tests? Wie finde ich die Schuldigen?

Testbarkeit war und ist IMHO ein Problem in der aktuellen EJB Spezifikation.