Adding ClassSubject#isAnnotatedWith(Class)

[benjamin-bader]

How does Truth feel about adding things to ClassSubject?

There are assertions that I'd like to make using reflection (e.g. assertThat(someClass).isAnnotatedWith(Singleton.class);) that aren't currently supported without custom subjects. Is there any strong feeling for or against adding at least this assertion?

I haven't thought very deeply about inheritance, and there are probably arguments to be made in that area. If there isn't any opposition, I'll fork and get to work on it.

Thanks!

[kluever]

Added it to our API review for today...thanks!

[cgruber]

Sorry - we didn't get to it in API review this week. But at a high level, I
like the concept.

On Tue, Oct 7, 2014, 08:09 Kurt Alfred Kluever notifications@github.com
wrote:

Added it to our API review for today...thanks!

—
Reply to this email directly or view it on GitHub
#139 (comment).

[benjamin-bader]

No worries. Would it be better to defer work on this until after it is addressed in review?

[kluever]

@benjamin-bader Yep - let's hold off until it's greenlit @ API review. Thanks!

[kluever]

Looks like we never ended up discussing this, but I think we'd like to hear a bit more about the use-case you had in mind?

[benjamin-bader]

Sure. The impetus for me was writing some Jersey Injectable implementations which, to be automatically registered with the runtime, must be annotated with @Provider. I think assertThat(klass).isAnnotatedWith(Provider.class) reads much more nicely than assert_().that(anno).named("has @Provider").isNotNull().

Since then, I've been playing around with generated classes and wishing to ensure that they have the expected annotations, but that's a decidedly more unusual case (for me, at least).

The important point to me is that there are cases where a missing or incorrect annotation will cause incorrect behavior at runtime, but whose absence/misuse will not be caught by the compiler - therefore requiring test coverage.