Tech Talk: ArchUnit – Unit-Tests zum Forcieren der Architektur
Ein neuer Tech Talk hat bei der Faktor Zehn stattgefunden. Dieses mal ging es um ArchUnit – Unit-Tests zum Forcieren der Architektur. Lesen Sie im folgenden Blogartikel die Zusammenfassung des spannenden Vortrags von unserem Kollegen Aykut:
Viele Projekte haben das Problem, dass Design- und Architekturentscheidungen mit der Zeit nicht eingehalten werden. Von der Unwissenheit eines neuen Entwicklers über einen schnellen Bugfix bis hin zur Konzentrationsschwäche des erfahrensten Entwicklers. Architektur- und Designverletzungen schleichen sich immer wieder ein. ArchUnit gibt uns Mittel, die Grenzen und Verwendungsabsichten unseres Codes bis ins kleinste Detail zu definieren und hält durch automatisiertes Testen unsere Codebasis frei von Ausreißern. Die Anhäufung von technischen Schulden wird somit reduziert und das System bleibt wartungsfreundlich.
Wir werfen einen Blick auf ArchUnit und schauen, wie es uns dabei helfen kann, die fehlerhafte Verwendung des Codes zu vermeiden.
Eingrenzen der betroffenen Pakete und Selektion der Klassen
Um ArchUnit zu verwenden sind keine zusätzlichen Werkzeuge nötig. Zum Forcieren einer Architekturregel oder Coding-Konvention wird lediglich ein gewöhnlicher JUnit Test benötigt.
Wie im oberen Bild zu sehen, werden zuerst die betroffenen Pakete eingegrenzt. In diesem Falle werden sämtliche Klassen importiert, die aus dem Paket „de.faktorzehn“ stammen. Im Anschluss wird die ArchRule definiert. Diese geht immer nach dem Schema „classes that ${PREDICATE} should ${CONDITION}“. Im Prädikat werden, anhand der angegebenen Kriterien, die betroffenen Klassen selektiert und in der Bedingung werden diese Klassen der Regel entgegengehalten.
Regeln in ArchUnit
Die Regeln, die sich mit ArchUnit definieren lassen, können kategorisiert werden als Abhängigkeits-, Eindämmungs-, Vererbungs-, Annotations-, Schichtenprüfung und Zyklische Prüfung.
Abhängigkeitsprüfung:
Die erste der beiden Abhängigkeitsprüfungen definiert, dass keine Klasse aus dem Paket „web“
Abhängigkeiten auf eine Klasse aus dem Paket „persistence“ haben darf. Alle anderen Pakete, wie z. B. „business“, sind jedoch erlaubt.
Die andere Prüfung besagt, dass scharfe Gegenstände (beispielsweise Messer) nur von Erwachsenen verwendet werden dürfen. Andere Klassen, wie z. B. das Baby, dürfen das nicht.
Wie im Bild zu sehen, werden für die Schichtenprüfung die einzelnen Schichten erst definiert und im Anschluss die erlaubten Abhängigkeiten untereinander festgelegt. Beispielsweise kann nun eine Klasse aus der Schicht „Webapp“ nicht mehr auf eine Klasse aus der Schicht „Business“ zugreifen, auch wenn es durch transitive Abhängigkeiten der Maven-Module möglich wäre.
Das gleiche Spiel lässt sich nicht nur auf Klassen anwenden, sondern auch auf Felder, Methoden, Konstruktoren usw. Außerdem besteht die Möglichkeit, Regeln in einem separaten Projekt zu definieren und später produktübergreifend anzuwenden.
Fazit
Im Allgemeinen lässt sich sagen, dass ArchUnit ein sehr mächtiges Werkzeug ist, welches mit einer flexiblen und leicht erweiterbaren API brilliert. Wer sich oft über Architektur- und Konventionsverstöße aufregt, wird ArchUnit sehr schnell ins Herz aufnehmen.
Zum Autor: Aykut arbeitet als Developer bei der Faktor Zehn und entwickelt seit Mai 2020 mit an der Schadensmanagement-Software Faktor-ICS.
Euer Faktor Zehn-Team
