CI the architecture of Java / Kotlin applications with ArchUnit

** (Addition) **

It was announced at JJUG CCC 2019 Spring.

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

Currently, my team is working on Development of new HRTech services, and recently launched a tool called ** ArchUnit **. I will introduce it because it has been incorporated.

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

I read a book called Evolutionary Architecture and measured / guaranteed the degree of compliance with the requirements of the characteristics of the architecture ** Fitness function ** 1 As an example, JDepend that can test class dependencies is introduced, and when I searched for a similar tool, ArchUnit I found. It was also introduced as TRIAL in this year's Technology Radar VOL.19.

What is ArchUnit?

• In a nutshell, it's a test framework that allows you to express and test JUnit test code for Java / Kotlin application package and class dependencies.
• In addition to dependencies, you can also test implementation rules such as product-specific naming conventions.
• First ArchUnit (Qiita) is easy to understand as an introductory article.

What are you happy about

• What can be tested with ArchUnit can be covered manually, for example, by documenting it and making it known, or by pointing it out in a code review. However, when humans check, it is difficult to remember them every time, so it is still valuable to be able to automate them.
• Architectural and product-specific implementation rules are coded, making tacit knowledge about design explicit knowledge.
• Development teams with varying technical capabilities can secure the architecture design with a certain force.
• Helps find implementations in legacy code that violate unwritten conventions and conventions

Concrete example

Here is a portion of the test code embedded in the CI of the product currently under development.

(1) A general-purpose class common to domains must not depend on classes of other specific domains.

Prevents the common package from becoming non-common.

• As a premise, the dependency of the domain layer (domain package) itself for other layers is implemented separately Layer Checks It shall be secured by the test.

@Test
void domainCommonPackageShouldNotDependOnOtherPackages() {
    noClasses()
        .that().resideInAPackage(ROOT_PACKAGE + ".domain.common..")
        .should()
        .dependOnClassesThat(new DescribedPredicate<>("Classes other than the common package under the domain package") {
            @Override
            public boolean apply(JavaClass clazz) {
                return clazz.getPackageName().startsWith(ROOT_PACKAGE + ".domain")
                    && ! clazz.getPackageName().equals(ROOT_PACKAGE + ".domain") //The base interface directly under the domain package/Dependence on class is acceptable
                    && ! clazz.getPackageName().startsWith(ROOT_PACKAGE + ".domain.common");
            }
        })
        .check(CLASSES);
}

(2) An enum that implements JsonSerializable must also implement a deserialization method.

When deserializing a JSON property into a numeric enumeration, if you don't explicitly implement the deserialization method, the JSON library's JSON library will instantiate the enumeration that corresponds to the ordinal value of the enumeration instead of the enumeration that corresponds to the number. I was once addicted to the specifications.

Added a test to check for forgetting to implement the deserialization method (factory method annotated with @JsonCreator) so that you don't get hooked on the same thing twice.

@Test
void jsonSerializableShouldImplementJsonCreator() {
        classes()
            .that(new DescribedPredicate<>("JSON serialized enum") {
                @Override
                public boolean apply(JavaClass clazz) {
                    return clazz.isEnum() && clazz.isAssignableTo(JsonSerializable.class);
                }
            })
            .should(new ArchCondition<>("@Implement the annotated factory method 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);
}

Summary

What did you think. I don't think there are many tools to test the architecture before. In addition to the examples introduced this time, it seems that tests from various perspectives can be implemented depending on the idea. It would be exciting if we could continuously improve the architecture through product development while ensuring the quality of the architecture through automated testing: smile: