Test your software Architecture with ArchUnit

[ythirion]

Hi community,
What if I say that we can put our Clean Architecture under tests ?

It is the promise of a library called ArchUnit : Unit Test your Architecture.
You can really make your architecture and its related rules explicit through your test suite by describing architecture rules.
It is pretty well integrated with JUnit in java and xUnit in .NET.
You can automate checks like :

• Inward dependency rule (Use Cases ---> Domain but the opposite is forbidden for example)
• Cycle dependencies (class A depends on B that depends on C that depends on A for example)
  • Pretty hard to identify in some cases
• Namespace containment rule -> every Controller classes should be a given namespace for example
• Keep your Domain "pure" (no technical related stuff -> attribute / annotations for example)
• Naming conventions in your code
• Coding guidelines : all the interface should start with a big I in C# for example
• Return types for public methods on given classes
  • Check that your Controller public method all return your own API Envelop for example
• Detect some linguistic anti-patterns
  • is / has function that should return a boolean
  • get functions should not return void
  • Other anti-patterns here

I have some slides on my own usage here and a repository with code examples in C# / java / scala here

What do you think about it ?
What other Use Cases do you identify for this library ?

[valentinajemuovic]

@ythirion excellent, thanks a lot!

This is really useful, testing the architecture itself - the dependencies - and learning more about the dependencies by reading the tests.

To classify the above, I'm now seeing the following "groups":

Clean Architecture:

• Inward dependency rule (Use Cases ---> Domain but the opposite is forbidden for example)
• Keep your Domain "pure" (no technical related stuff -> attribute / annotations for example)

General - Naming:

• Namespace containment rule -> every Controller classes should be a given namespace for example
• Naming conventions in your code
• Coding guidelines : all the interface should start with a big I in C# for example
• Detect some linguistic anti-patterns

General - Access

• Return types for public methods on given classes

General - Dependecies

• Cycle dependencies (class A depends on B that depends on C that depends on A for example)

After reading your list, additional ideas I have are:

• Requests & Responses should have public getters / setters, and no constructors, no methods
• UseCase should not have any additional public methods aside from the handle() method
• UseCase should only have interfaces injected into them, not concrete classes
• UseCases and domain entities should not have the call to DateTime.Now , or LocalDateTime.Now()
• (Optional) Value objects (implemented as structs in the Domain layer) should have the From method for construction (ok. this is an example, I'm weighing back-and-forth between constructors vs factory methods, I guess that's a wider topic than ArcUnit)
• Domain entities should not have the auto-generated public setter properties (in .NET), must be coded (that way we ensure that if there is setting that invariance is upheld)
• There must not be any reference to JPA / Hibernate / Entity Framework from neither domain nor use cases
• Domain entities should not have any interfaces injected into them (I guess this one is subjective)

The above is a rough list I thought of now, I will check what is possible, at the moment I'm reading the code you added for the banking Kata (.NET) to learn more about usage, so I'll let you know after I extend it further.