Unit Testing für Architektur Vorgaben

Neben den Unit Tests für einzelne Methoden kann man auch generelle Vorgaben prüfen, welche die gesamte Architektur erfüllen muss. Dazu gibt es das ArchUnit Paket.

In meinem Demo Projekt habe ich das mal in aller Breite beispielhaft aufgebaut:

  • Requirements (in Testlink)
  • Logische Testcases (ebenfalls in Testlink)
  • Physische Testcases (im Java Maven Projekt)

OpenJDK läuft

Zuerst war ich ja etwas kritisch, außerdem lief bei einer alten Version der maven download nicht mehr, da die Zertifikate fehlten.

Aber nun mit der aktuellen 8er und 11er Version vom OpenJDK klappt es vorzüglich und gefühlt kompiliert der ganze Stapel richtig schnell durch. Sämtliche Unittests sind grün, alles compiliert, nichts klemmt. Perfekt!

Git rebase mit Handbremse

Wenn man sich wundert, warum eine einzige geänderte Datei beim rebase über Minuten den PC lahm legt (Windows natürlich). Wenn parallel Eclipse offen ist und bei jeder kleinen Änderung sofort neu compilieren will, dann bremst das natürlich ein wenig.
Dazu noch eine virtualisierte Umgebung und man kann erst mal Kaffee holen.

Java X-tool

Egal ob mal eben ein XML oder ein XLSX File zu parsen ist, mit Java kann auch das schnell von der Hand gehen. Dank Maven Unterstützung ist das ganze in einer Stunde schnell hingezaubert. An manchen tagen läuft es einfach.

Namen von Variablen

Viel zu schnell hat man sich mal vertippt bei der Referenz zu einer Variablen. Wenn dann eine andere Variable fast genauso benannt wurde, ist der Fehler kaum zu finden:

for (TestMap testMap : this.testMaps)
{
    System.out.println(testMaps.toString());
}

Das eine gemeine Plural s hat sich also reingemogelt. Dem Compiler ist das egal. Gemeint war aber eher dieser Aufruf:

for (TestMap testMap : this.testMaps)
{
    System.out.println(testMap.toString());
}

Der Unterschied ist kaum merklich. Also hätte man besser etwas längere Namen genutzt, die sich gleich in mehr Zeichen unterscheiden:

for (TestMap oneTestMap : this.allTestMaps)
{
    System.out.println(oneTestMap.toString());
}

So sollte es besser lesbar sein.

Java 11 Migration

So ein Sprung von Java 1.8 zu Java 11 macht schon einige kleinere Probleme. Die eigene Programmierung ist da noch das kleinste Problem, aber der CI Stack mit Code Coverage und Änderungen im Bytecode bringt einen Haufen zu aktualisierender Maven Pakete mit sich. Und da kaum jemand an einen Änderungsarmen Updatepfad denkt, muss man sich erst durch viele Changelogs arbeiten.

Aber nun läuft das JaStaCry Projekt wieder stabil, alles im grünen Bereich und Java 11 schnuckelt selbst im Jenkins ohne Probleme.