Mit einer Bibliothek namens ** ArchUnit ** kann durch Unit-Test überprüft werden, ob der Java-Quellcode die Architektur verletzt.
Ich werde vorstellen, was Sie mit ArchUnit tun können, welche Art von Code es tatsächlich sein wird usw.
ArchUnit ist eine Open Source Library, mit der Sie Komponententests für die Java-Architektur durchführen können. Es ist eine bemerkenswerte Bibliothek, die auch in TECHNOLOGY RADAR veröffentlicht wurde.
Mit ArchUnit können Sie Folgendes mit einem Komponententest überprüfen. (*)
Es ist weniger wahrscheinlich, dass Architekturverletzungen auftreten.
Traditionell, um die Architektur sauber zu halten
Ich denke, dass ich oft analoge Maßnahmen ergriffen habe wie. Wenn daher ein menschlicher Fehler auftritt, wird der Code, der die Architektur verletzt, in den Hauptzweig gestellt.
Bei Verwendung von ArchUnit können Komponententests Architekturverletzungen erkennen, sodass CI nach Architekturverletzungen suchen kann. Wenn die Tests korrekt geschrieben sind, kann der zusammengeführte Code keine Architekturverletzung verursachen.
Die Installationsmethode wird in [hier] beschrieben (https://www.archunit.org/userguide/html/000_Index.html#_installation). Den unten gezeigten Code finden Sie unter hier. (Getestet mit JUnit 5)
Wenn Sie einen Test mit ArchUnit schreiben, weisen Sie der Testklasse zuerst "@ AnalyzeClasses" zu. Die Klassen, die in dem durch "Pakete" angegebenen Paket enthalten sind, werden getestet.
@AnalyzeClasses(packages = "nannany.arch.check.archunit")
public class ArchitectureTest {
Im Folgenden wird die Architektur überprüft, dass ein Paket mit "service" im Paketnamen nicht von einem Paket mit "controller" im Paketnamen abhängen kann.
/**
*Das Servicepaket ist unabhängig von der Steuerung
*/
@ArchTest
public static final ArchRule servicesCantDependOnController = noClasses()
.that().resideInAnyPackage("..service..")
.should().dependOnClassesThat().resideInAPackage("..controller..");
Die Beschreibungsmethode ist ein Bild des Schreibens der zu testenden Klasse auf der linken Seite von "should ()" und der Regel auf der rechten Seite von "should ()".
Im obigen Beispiel sollte für "noClasses (). That () .resideInAnyPackage (" .. service .. ")" die im Paket "service" enthaltene Klasse auf der rechten Seite von "should ()" stehen. Dies bedeutet, dass es keine Klasse gibt, die die Regel ** erfüllt.
Für dependOnClassesThat (). ResideInAPackage (" .. controller .. ");
drückt es die Regel aus, dass es vom Paket mit dem Namen controller
abhängt.
ArchUnit bietet Unterstützung für typische Architekturen. Derzeit [Multilayer-Architektur](https://ja.wikipedia.org/wiki/%E5%A4%9A%E5%B1%A4%E3%82%A2%E3%83%BC%E3%82%AD % E3% 83% 86% E3% 82% AF% E3% 83% 81% E3% 83% A3) und Zwiebelarchitektur (hexagonale Architektur)) Es scheint Unterstützung für zu geben.
Im Folgenden verwenden wir Methoden, die mehrschichtige Architekturen unterstützen, um den Zugriff zwischen anderen Schichten als "Controller → Service → Persistenz" zu überprüfen.
/**
*Verwenden einer geschichteten Architektur
*/
@ArchTest
public static final ArchRule layeredArchitecture = layeredArchitecture()
.layer("Controllers").definedBy("nannany.arch.check.archunit.controller")
.layer("Services").definedBy("nannany.arch.check.archunit.service")
.layer("Repositories").definedBy("nannany.arch.check.archunit.repository")
.whereLayer("Controllers").mayNotBeAccessedByAnyLayer()
.whereLayer("Services").mayOnlyBeAccessedByLayers("Controllers")
.whereLayer("Repositories").mayOnlyBeAccessedByLayers("Services");
https://www.archunit.org/ https://www.thoughtworks.com/radar/tools/archunit
Recommended Posts