Add annotation Class navigation method

[michaelcowan]

Check List:

• Unit tests : YES
• Javadoc with a code example (on API only) : YES
• PR meets the contributing guidelines

Add hasAnnotationSatisfying Class assertion.

This can be useful when needing to both assert that an annotation is present but also has specific parameter values
e.g., A Spring Boot engineer might want to verify specifically configured transactionals:

assertThat(MyService.class)
    .hasAnnotationSatisfying(Transactional.class, transactional ->
        assertThat(transactional)
            .extracting(Transactional::noRollbackFor)
            .isEqualTo(SendMailFailureException.class));

[scordio]

What about a navigation method to change the object under test?

Something like:

assertThat(MyService.class)
  .annotation(Transactional.class) // would return an AbstractObjectAssert<?, Transactional>
  .extracting(Transactional::noRollbackFor)
  .isEqualTo(SendMailFailureException.class));

[michaelcowan]

@scordio That was actually my first instinct too, but I changed my mind when I considered:

1. The existing pattern of isInstanceOf and isInstanceOfSatisfying
   • Which also supports chaining more assertions
2. We already have hasAnnotation

This made me think that what we are missing is a hasAnnotationSatisfying assertion.

Happy to change this, I just want to be sure that what we want is to have both:

assertThat(MyService.class)
  .hasAnnotation(Transactional.class);

-and-

assertThat(MyService.class)
  .annotation(Transactional.class)
  // ...

[scordio]

We discussed it internally and we would generally favor navigation methods for new APIs.

hasAnnotation(...) can still have a purpose if no navigation is needed, similar to hasCause() and cause() for Throwable assertions.

As a side note, asInstanceOf also acts as a navigation method alongside isInstanceOf 🙂

[michaelcowan]

@scordio Understood - I've pushed those changes to the branch.

[michaelcowan]

@scordio Do you want me to open a new PR and close this one?