You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implement layer rules #1 adds a rule to the central ArchitectureTest that defines the same layers redundantly
A project that wants to copy&paste the solution from this repo into their codebase would have to adopt layer names in multiple places in case they wanted to rename a layer (e.g. client to ui / dataaccess to data / logic to domain).
For sharing such constants, we should use default/package visibility (remove private keyword).
Further, we should come to a final agreement how we want to do modularization of the architecture tests:
Have a single JUnit class ArchitectureTest that executes all rules but define separate classes (with default/package visibility) in the same package that are just aggregated by ArchitectureTest so the JUnit does not contain any logic but just the reference to all the individual rules.
Having multiple JUnit classes per aspect. This is what we are doing but only partially. So if we name an aspect NamingConventionTest or PackageRuleTest then we IMHO would also need to define the layer rules (Implement layer rules #1) in LayerRuleTest.
The first approach has the advantage that a developer can check all architecture tests with a single invocation of a JUnit in his IDE. While the second one allows to run tests only for individual aspects.
I will try to collect feedback from customer projects using archunit on their experience and philosophy on this.
IMHO the launch of an archunit test is time consuming (@AnalyzeClasses triggers classpath scanning what needs to scan the entire code-base and gets slower the more code you have) and typically developers prefer to have a single test to run for architecture validation and only waiting once for several seconds (in our very small demo it is however, just ~1 second per archunit test what is never an issue - I have seen a large monolithic project where it took ~60 seconds).
We have already implemented various rules in arbitrary stories and PRs what is really great.
Now it is time to revisit, align, and refactor:
ArchitectureTestthat defines the same layers redundantlyA project that wants to copy&paste the solution from this repo into their codebase would have to adopt layer names in multiple places in case they wanted to rename a layer (e.g.
clienttoui/dataaccesstodata/logictodomain).For sharing such constants, we should use
default/package visibility(removeprivatekeyword).Further, we should come to a final agreement how we want to do modularization of the architecture tests:
ArchitectureTestthat executes all rules but define separate classes (withdefault/package visibility) in the same package that are just aggregated byArchitectureTestso the JUnit does not contain any logic but just the reference to all the individual rules.NamingConventionTestorPackageRuleTestthen we IMHO would also need to define the layer rules (Implement layer rules #1) inLayerRuleTest.The first approach has the advantage that a developer can check all architecture tests with a single invocation of a JUnit in his IDE. While the second one allows to run tests only for individual aspects.
I will try to collect feedback from customer projects using archunit on their experience and philosophy on this.
IMHO the launch of an archunit test is time consuming (
@AnalyzeClassestriggers classpath scanning what needs to scan the entire code-base and gets slower the more code you have) and typically developers prefer to have a single test to run for architecture validation and only waiting once for several seconds (in our very small demo it is however, just ~1 second per archunit test what is never an issue - I have seen a large monolithic project where it took ~60 seconds).