This module contains architecture tests using ArchUnit. Considering the isolation of classpath and rules for architectural tests, there are two top level categories:
Since both of them will need some common ArchUnit extensions, there are three submodules:
Following documentation is valid for building and maintaining the architectural tests both for the production code and the test code.
There are two cases in which architectural tests may fail due to changes in the codebase:
In the former case, please add the updated violation store file to your commit. The tests should now succeed.
If you have added a new violation, consider how to proceed. New violations should be avoided at all costs. First and foremost, evaluate whether the flagged violation is correct. If it is, try to rework your change to avoid the violation in the first place. However, if you believe that your code should not be flagged as a violation, open a JIRA issue so that the rule can be improved.
In order to have a new violation recorded, open archunit.properties
in the submodule and enable freeze.refreeze=true
. Rerun the tests and revert the change to the configuration. The new violation should now have been added to the existing store.
Please refer to the ArchUnit user guide for general documentation. However, there are a few points to consider when writing rules:
FreezingArchRule.freeze()
. This will add the rule to the violation store that records the existing violations. Add the new stored violations file within violations
to your commit.FreezingArchRule.freeze().as(String newDescription)
. This will reduce the maintenance effort for each rule update. Otherwise, since the description will be used as the key of the rule to define the violation store, new violation stores will be created and old obsolete stores have to be removed manually each time when rules have been changed.archunit.properties
in the submodule and enable freeze.store.default.allowStoreCreation=true
.GivenJavaClasses
.Scala is not supported by ArchUnit. Although it operates on the byte-code level and can, in general, process classes compiled from Scala as well, there are Scala-specific constructs that do not work well in practice. Therefore, all architecture rules should exclude non-Java classes.