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));

@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)
  // ...

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 🙂

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

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

@scordio If there anything from me blocking this being merged?

@michaelcowan no, not at all. We are focusing on releasing the first milestone of version 4 and haven't had the chance to finalize your PR.

I'll schedule these changes for M2, and apologies for the extremely slow feedback!