Was bringen Architektur-Tests?

Vermutlich kennst auch Du es, vor Dir ist ein Projekt mit vielen Klassen, Dateien, Ordnern und irgendwie wirkt alles auf Dich, als hätte es keinerlei Struktur. Wenn dieses Projekt keine Architektur-Tests vorweisen kann, ist dem vermutlich auch so.

Okay, man muss zugeben, vermutlich haben die meisten Entwickler versucht, nach bestem Wissen und Gewissen, sich an die Gegebenheiten anzupassen und danach zu entwickeln. Je nachdem wieviele Entwickler an diesem Projekt beteiligt sind oder wieviele Entwickler bereits daran gearbeitet haben, kann es sein, dass das Projekt zu einem wilden Mix aus verschieden Architektur-Konzepten zusammen geschustert wurde.

Es ist aber nicht immer nur so, dass viele in einem Projekt involviert sein müssen, damit das geschieht. Es reicht auch oft, wenn man alleine an einem privaten Projekt entwickelt. Man entscheidet sich für eine Namenskonvention und arbeitet nach dieser. Nach ein paar Tagen oder Wochen Inaktivität, ist diese Entscheidung bereits vergessen und man arbeitet mit einer anderen, sofern es nicht dokumentiert oder falls der Dokumentationsort bereits vergessen wurde.

Um sich nicht alle Entscheidungen “merken” zu müssen, können uns hier sogenannte Architektur-Tests helfen. Diese sind sehr mächtig und nicht nur auf folgende Beispiele beschränkt:

  • Abhängigkeiten prüfen
  • Namenskonventionen erzwingen
  • Sicherstellen, dass bestimmte Komponenten wie erwartet benutzt werden (Funktionsaufrufe prüfen)
  • Annotationen vorhanden

Hierzu, gibt es für die Java und .NET Welt ein Tool namens ArchUnit. Damit lassen sich alle oben genannten “Regeln” abbilden, der Fantasie ist hierbei beinahe keinerlei Grenze gesetzt. Die Prüfung erfolgt auf Basis des jeweiligen Bytecodes (Java oder C#), hierbei gibt es auch entsprechende Limitierungen, diese interessieren uns an dieser Stelle aber nicht.

Abschließend lässt sich sagen, dass es wichtig ist, so zeitnah wie möglich Architektur-Tests einzubauen. Diese helfen nicht nur Team- und/oder Architekturentscheidungen zu erzwingen, sondern erinnern uns auch, falls wir einmal wieder gegen die vorliegende Architektur verstoßen sollten.

Zu guter letzt, ein kleines Beispiel aus einem meiner Projekte. Hierbei erzwinge ich die Namenskonvention, dass RestController das auch im Namen haben

@ArchTest
static final ArchRule classes_annotated_with_restcontroller_should_have_restcontroller_in_their_name = classes()
            .that().areAnnotatedWith(RestController.class)
            .should().haveNameMatching(".*RestController");
2480cookie-checkWas bringen Architektur-Tests?

Kommentar verfassen