Seitenhistorie

...

Der große Vorteil eines Test Spring Contextes ist, dass man die zu testenden Klassen nicht verändern muss und auch keinen Boilerplate Code benötigt. Die Spring Injection funktioniert auch in den Tests weiterhin wie gewohnt, man muss 'nur' im Auge behalten, das der Test Spring Context (meist) viele Mock Objekte beinhaltet.

Nuclos und Unit Tests

Bei der praktischen Umsetzung von Unit Tests für Nuclos sind mir noch ein paar spezielle Dinge aufgefallen.

Nuclos Client, Common und Server

Da Nuclos ein Client-Server System ist, besteht es grob gesagt aus 3 Teilen:

1. Dem Nuclos Server, der auf dem Tomcat läuft
2. Dem Nuclos Client, der mittels Web Start gestartet wird und eine Swing GUI besitzt
3. Code, der in Nuclos Server und Client verwendet wird (beispielsweise die Value Objekte, die zwischen Server und Client ausgetauscht werden (RPC))

Diese Struktur findet man ähnlich auch in den Nuclos Maven Modulen wieder.

Unit Tests können ihrem Wesen nach nur in einem dieser Teile laufen (da die Unit Frameworks nur einen (Java-VM) Prozess erzeugen). Daher müssen im Server alle Anfragen des Client gemockt werden, und umgekehrt im Client alle Antworten des Servers. In der Praxis ist es praktisch unmöglich, Unit Tests für Swing Klassen zu schreiben, da sich die User Eingaben (per Maus und Tastatur) nicht auf einfachen Wege mocken lassen. Darüber hinaus ist die Trennung zwischen GUI und Logik im Nuclos Client Code nur sehr rudimentär vorhanden. Da sich ferner im gemeinsamen Code (fast) nur Value Objekte befinden, lassen sich Unit Test mit vertretbaren Aufwand hauptsächlich für den Nuclos Server erzeugen.

Metadaten von BOs und Feldern/Attributen