CI l'architecture des applications Java / Kotlin avec ArchUnit

** (Une addition) **

Il a été annoncé au JJUG CCC 2019 Spring.

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

Actuellement, mon équipe travaille sur Développement de nouveaux services HRTech, et a récemment lancé un outil appelé ** ArchUnit **. Je vais le présenter parce qu'il a été incorporé.

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

J'ai lu le livre Evolutionary Architecture et mesuré / garanti le degré de conformité aux exigences des caractéristiques de l'architecture ** Fonction d'adaptabilité ** 1 A titre d'exemple, JDepend qui peut tester les dépendances de classe est introduit, et quand j'ai cherché un outil similaire, ArchUnit J'ai trouvé. Il a également été présenté comme TRIAL dans le [Technology Radar VOL.19] de cette année (https://www.thoughtworks.com/radar/tools).

Qu'est-ce que ArchUnit?

• En un mot, c'est un framework de test qui vous permet d'exprimer et de tester le code de test JUnit pour le package d'application Java / Kotlin et les dépendances de classe.
• En plus des dépendances, vous pouvez également tester des règles d'implémentation telles que les conventions de dénomination spécifiques au produit.
• First ArchUnit (Qiita) est facile à comprendre en tant qu'article d'introduction

De quoi es-tu heureux

• Ce qui peut être testé avec ArchUnit peut être couvert manuellement, par exemple, en le documentant et en le faisant connaître, ou en le signalant dans une revue de code. Cependant, lorsque les humains vérifient, il est difficile de s'en souvenir à chaque fois, il est donc toujours utile de pouvoir les automatiser.
• L'architecture codée et les règles d'implémentation spécifiques au produit rendent formelle la connaissance implicite de la conception.
• Les équipes de développement avec des capacités techniques variables peuvent sécuriser la conception de l'architecture avec une certaine force.
• Aide à trouver les implémentations dans le code hérité qui violent les conventions et conventions non écrites

Exemple concret

Voici une partie du code de test intégré au CI du produit en cours de développement.

(1) Une classe à usage général commune aux domaines ne doit pas dépendre de classes d'autres domaines spécifiques.

Empêche le paquet «commun» de devenir non commun.

• En principe, la dépendance de la couche de domaine (package de domaine) elle-même pour les autres couches est implémentée séparément Layer Checks Il doit être sécurisé par l'essai.

@Test
void domainCommonPackageShouldNotDependOnOtherPackages() {
    noClasses()
        .that().resideInAPackage(ROOT_PACKAGE + ".domain.common..")
        .should()
        .dependOnClassesThat(new DescribedPredicate<>("Classes autres que le package commun sous le package de domaine") {
            @Override
            public boolean apply(JavaClass clazz) {
                return clazz.getPackageName().startsWith(ROOT_PACKAGE + ".domain")
                    && ! clazz.getPackageName().equals(ROOT_PACKAGE + ".domain") //interface de base de domaine directement sous le package/La dépendance de classe est acceptable
                    && ! clazz.getPackageName().startsWith(ROOT_PACKAGE + ".domain.common");
            }
        })
        .check(CLASSES);
}

(2) L'énumération qui implémente JsonSerializable doit également implémenter la méthode de désérialisation.

Lors de la désérialisation d'une propriété JSON en une énumération numérique, si vous n'implémentez pas explicitement la méthode de désérialisation, l'énumération correspondant à la valeur ordinale de l'énumération sera instanciée au lieu de l'énumération correspondant à la valeur numérique. J'étais une fois accro aux spécifications.

Ajout d'un test pour vérifier si vous avez oublié d'implémenter la méthode de désérialisation (méthode d'usine annotée avec @ JsonCreator) afin que vous ne soyez pas accroché deux fois à la même chose.

@Test
void jsonSerializableShouldImplementJsonCreator() {
        classes()
            .that(new DescribedPredicate<>("Énumération sérialisée JSON") {
                @Override
                public boolean apply(JavaClass clazz) {
                    return clazz.isEnum() && clazz.isAssignableTo(JsonSerializable.class);
                }
            })
            .should(new ArchCondition<>("@Implémenter la méthode de fabrique annotée dans 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);
}

Résumé

Qu'as-tu pensé. Je ne pense pas qu'il y ait eu beaucoup d'outils pour tester l'architecture. En plus des exemples présentés cette fois, il semble que des tests sous différents angles puissent être mis en œuvre en fonction de l'idée. Ce serait passionnant si nous pouvions améliorer continuellement l'architecture grâce au développement de produits tout en garantissant la qualité de l'architecture grâce à des tests automatisés: smile: