your current architecture rules inside your team and how you ensure that your code is always matching those rules Examples : All our events must reside in the events package Our repository layer can only be accessed through our application layer …
checking the architecture of your Java code. It does so by analyzing given Java bytecode, importing all classes into a Java code structure. ArchUnit’s focus is to automatically test architecture and coding rules, using any plain Java unit testing framework.
code and drew up some nice architecture diagrams, showing the components the system should consist of, and how they should interact. But when the project got bigger, the use cases more complex, and new developers dropped in and old developers dropped out, there were more and more cases where new features would just be added in any way that fit. And suddenly everything depended on everything, and every change could have an unforeseeable effect on any other component. Of course, you could have one or several experienced developers, having the role of the architect, who look at the code once a week, identify violations and correct them. But a safer way is to just define the components in code and rules for these components that can be automatically tested, for example as part of your continuous integration build.” ArchUnit’s promise
to maintain clean boundaries between layers Team rules can easily be broken by inadvertence • Document your architecture decisions (at least structural ones) With a clear DSL • Automate their check and ensure to respect them at any time Can easily be checked with ScalaTest in your CI
create custom rules, imagine in your team you decide… that interfaces should always be prefixed by a big I that controller classes should be in their dedicated package
Methods that do the opposite than they say Methods that do more than they say Methods that say more than they do Identifiers whose name says that they contain more than what the entity contains Identifiers whose name says that they contain less than what the entity contains Identifiers whose name says that the opposite than the entity contains
in 7 huge open-source projects : 11% of setters also return a value in addition to setting a field 2.5% of methods : method name and the corresponding comment gave opposite descriptions of the working of the method 64% of identifiers starting with ‘is’ turned out not to be Boolean
? You could declare some of those rules in Sonar BUT Cost less with ArchUnit Easier rule creation We can check high level rules as well as fine-grained Layer constraints Class A cannot have dependencies on something else … We have fast feedback Even with SonarLint Already integrated in your CI / CD Just a dependency to add Rules automation with XUnit