CI die Architektur von Java / Kotlin-Anwendungen mit ArchUnit

** (Ergänzung) **

Dies wurde auf der [JJUG CCC 2019 Spring] angekündigt (http://www.java-users.jp/ccc2019spring/#/sessions/2e1e4779-b1ae-4864-a319-2b1262eba09c).

How to check and improve the Java-based application architecture with “ArchUnit” https://speakerdeck.com/kawanamiyuu/jjug-ccc-2019-spring

Derzeit arbeitet mein Team an Entwicklung neuer HRTech-Dienste und hat kürzlich ein Tool namens ** ArchUnit ** gestartet. Ich werde es vorstellen, weil es aufgenommen wurde.

• GitHub: https://github.com/TNG/ArchUnit
• User Guide: https://www.archunit.org/userguide/html/000_Index.html

Ich habe das Buch Evolutionäre Architektur gelesen und den Grad der Übereinstimmung mit den Anforderungen der Eigenschaften der Architektur gemessen / garantiert ** Anpassungsfähigkeitsfunktion ** 1 Als Beispiel wird JDepend vorgestellt, mit dem Klassenabhängigkeiten getestet werden können, und als ich nach einem ähnlichen Tool suchte, ArchUnit Ich fand. Es wurde auch als TRIAL im diesjährigen Technology Radar VOL.19 eingeführt.

Was ist ArchUnit?

• Kurz gesagt, es ist ein Testframework, mit dem Sie JUnit-Testcode für Java / Kotlin-Anwendungspaket- und Klassenabhängigkeiten ausdrücken und testen können.
• Zusätzlich zu Abhängigkeiten können Sie auch Implementierungsregeln wie produktspezifische Namenskonventionen testen.
• First ArchUnit (Qiita) ist als einleitender Artikel leicht zu verstehen

Worüber freust du dich?

• Was mit ArchUnit getestet werden kann, kann manuell behandelt werden, indem beispielsweise dokumentiert und bekannt gemacht oder in einer Codeüberprüfung darauf hingewiesen wird. Wenn Menschen dies überprüfen, ist es jedoch schwierig, sich jedes Mal an sie zu erinnern. Daher ist es immer noch wertvoll, sie automatisieren zu können.
• Codierte Architektur und produktspezifische Implementierungsregeln machen implizites Wissen über das Design formal.
• Entwicklungsteams mit unterschiedlichen technischen Fähigkeiten können das Architekturdesign mit einer bestimmten Kraft sichern.
• Hilft bei der Suche nach Implementierungen in Legacy-Code, die gegen ungeschriebene Konventionen und Konventionen verstoßen

Konkretes Beispiel

Hier ist ein Teil des Testcodes, der in das CI des derzeit in der Entwicklung befindlichen Produkts eingebettet ist.

(1) Eine für Domänen gemeinsame Allzweckklasse darf nicht von Klassen anderer spezifischer Domänen abhängen.

Verhindert, dass das "gemeinsame" Paket nicht allgemein wird.

• Als Voraussetzung wird die Abhängigkeit der Domänenschicht (Domänenpaket) selbst von anderen Schichten separat implementiert Layer Checks. Es ist durch die Prüfung zu sichern.

@Test
void domainCommonPackageShouldNotDependOnOtherPackages() {
    noClasses()
        .that().resideInAPackage(ROOT_PACKAGE + ".domain.common..")
        .should()
        .dependOnClassesThat(new DescribedPredicate<>("Andere Klassen als das allgemeine Paket unter dem Domänenpaket") {
            @Override
            public boolean apply(JavaClass clazz) {
                return clazz.getPackageName().startsWith(ROOT_PACKAGE + ".domain")
                    && ! clazz.getPackageName().equals(ROOT_PACKAGE + ".domain") //Domain Base-Schnittstelle direkt unter dem Paket/Klassenabhängigkeit ist akzeptabel
                    && ! clazz.getPackageName().startsWith(ROOT_PACKAGE + ".domain.common");
            }
        })
        .check(CLASSES);
}

(2) Die Aufzählung, die JsonSerializable implementiert, muss auch die Deserialisierungsmethode implementieren.

Wenn Sie beim Deserialisieren einer JSON-Eigenschaft in eine numerische Aufzählung die Deserialisierungsmethode nicht explizit implementieren, wird die dem Ordnungswert der Aufzählung entsprechende Aufzählung anstelle der dem numerischen Wert entsprechenden Aufzählung instanziiert. Ich war einmal süchtig nach den Spezifikationen.

Es wurde ein Test hinzugefügt, um zu überprüfen, ob vergessen wurde, die Deserialisierungsmethode (mit @ JsonCreator annotierte Factory-Methode) zu implementieren, damit Sie nicht zweimal an derselben Sache hängen bleiben.

@Test
void jsonSerializableShouldImplementJsonCreator() {
        classes()
            .that(new DescribedPredicate<>("JSON serialisierte Aufzählung") {
                @Override
                public boolean apply(JavaClass clazz) {
                    return clazz.isEnum() && clazz.isAssignableTo(JsonSerializable.class);
                }
            })
            .should(new ArchCondition<>("@Implementieren Sie die mit Anmerkungen versehene Factory-Methode in JsonCreator") {
                @Override
                public void check(JavaClass clazz, ConditionEvents events) {
                    boolean hasJsonCreator = clazz.getMethods().stream()
                        .anyMatch(method -> method.isAnnotatedWith(JsonCreator.class));

                    if (! hasJsonCreator) {
                        events.add(SimpleConditionEvent.violated(
                            clazz,
                            clazz.getName() + " should implement a factory method annotated with @JsonCreator."
                        ));
                    }
                }
            })
            .check(CLASSES);
}

Zusammenfassung

Was haben Sie gedacht. Ich glaube nicht, dass es viele Tools gab, um die Architektur zu testen. Zusätzlich zu den diesmal vorgestellten Beispielen können je nach Idee Tests aus verschiedenen Perspektiven durchgeführt werden. Es wäre aufregend, wenn wir die Architektur durch Produktentwicklung kontinuierlich verbessern und gleichzeitig die Qualität der Architektur durch automatisierte Tests sicherstellen könnten: smile: