Provide basic rule definitions for fields, methods, constructors...

[codecholeric]

We should add to ArchRuleDefinition the factory methods

• GivenFields fields()
• GivenMethods methods()
• GivenConstructors constructors()
• GivenCodeUnits codeUnits()
• GivenMembers members()

that provide an easy entrance to speak about the respective objects, i.e. provide a that(predicate) and should(condition) fluent API. At some later point, this API can be extended for generally useful methods like declaredIn(clazz) or similar.

[stefluhh]

Hi @codecholeric ,

do you already have ideas how to design the DSL for fields(), methods(), constructors() etc. when it is desired to relate to the class the fields, methods, constructors reside in?

My first idea would be something newly specific for that like this:

fields().whoseClasses()

This would enable the opportunity to reuse all thats() on classes level right? :)
Concrete usage in my use case would be:

fields()
     .that().haveName("userId")
     .and().whoseClasses().areAnnotatedWith(Aggregate.class)
     .should().beAnnotatedWith(Indexed.class)
     .because("UserId is an aggregate reference and we have finders on UserId.");

This would also lead to my next question, I would like to write ArchTests for specific classes only to make sure, that a certain constructor is annotated with @PersistenceConstructor or that only particular fields in that class are annotated with Spring Data MongoDb Indexed annotation.

This would probably be possible with something like this:

@RunWith(ArchUnitRunner.class)
@AnalyzeClass(Order.class)
public class RepositoryArchTest {

   @ArchTest
   public void enforceThat_UserId_IsIndexedForMongoDb(JavaClasses javaClasses) throws Exception {
      field()
              .that().hasName("userId")
              .should().beAnnotatedWith(Indexed.class)
              .check(javaClasses);
   }
}

However one could argument that this is also easily possible with java.lang.Class even:

Field userId = Order.class.getDeclaredField("userId");
assertTrue("UserId must be indexed in Mongo because there is a finder implemented for UserId", 
        userId.isAnnotationPresent(Indexed.class));

However only the existence of ArchUnit made me think of such test cases for the first time.

[codecholeric]

I pretty much had the same idea about reusing the class predicates for member assertions, my idea was, to call it

fields().that().areDeclaredIn() (.classesThat()/.packagesThat()/...)

😉
You are right about your observations in the second part, ArchUnit only provides an advantage over directly using reflection, if

• You need non-local information (2+ classes in connection)
• You want to be independent of the classpath
• You can use some of the succinct syntax

Other than that, ArchUnit was created with a strong idea of providing an "extension" of reflection, so if you only use a subset, it might be well possible to assert all those things with reflection alone.

However, I would use ArchUnit anyway, simply for having all tests together in a consistent way. (only talking from my own experience, I used to write those tests with a whole arsenal of tools from reflection to AspectJ, and it certainly doesn't make it easier to understand, where certain new tests should go and which places you have to observe in the CI build)

Anyway, this issue will unfortunately only provide the basic entry point for fields, methods, ..., you'll have to be patient to get the full fluent API 😉

[raspacorp]

@codecholeric I saw your commits where you are adding support for fields and methods in archrules, it looks great, I am currently working on a task of verifying that methods annotated with a specific annotation have an attribute set up. Do you know if these changes will be part of the next release? Thanks.

[codecholeric]

@raspacorp Yes, this is planned for the next release. However I don't have a fixed date except for sometimes within the next 2 months 😉
Other than that using AbstractClassesTransformer to transform classes to methods (all(methods()).that(..).should(..)) should also not be terribly much code I hope (there are a lot of predefined predicates for JavaMethod and co., by convention always in JavaXXX.Predicates).