Why mix annotation-based and method-based mocks? This could become another annotated field.

There are three tests, one calls the bug instance suppressed, the second calls it reported and the third one does not create a bug instance, so I think it makes sense that @mafor used a local variable here

There is no need for the tests to use different names for the instance. As I see it, we just have 2/3 tests creating an instance mock, so it makes sense to be consistent with other values by making it an annotated field.

I have made the change to create the instance with @Mock

Error messages should give more detail about the failed value(s) if possible, especially for assertTrue (which doesn't give much detail natively)

I've looked into this and do not see a practical way for the matcher to return why the instance wasn't matched.
We're using the term matcher for two separate things:

• the suppression matchers we're using to filter out detected bugs
• the hamcrest matchers we're using in unit tests (these matchers do provide messages)

I think it is fine to leave the test like that, it is short enough so we can reason about it

The message could at least specify which suppression matcher is being applied? It could be deduced anyway by tracing the test, but seeing it at a glance is better.

The suppressor is mocked here, so there's no real reason for the instance to be suppressed besides the suppressor being mocked to return false.

Should this be in init?

The two tests mock objects differently:
when(suppressor.match(bugInstance)).thenReturn(true);
and:
when(suppressor.match(bugInstance)).thenReturn(false);

So I think this can't be factored in init

Those lines are different, yes, but making the suppressor return the instance is the same in both.

Sorry, I don't follow: the suppressor does not return the instance and I don't think that it would be clearer to extract this:

OngoingStubbing<Boolean> when = when(suppressor.match(bugInstance));

Line 57, specifically, is duplicated across multiple tests, and could be extracted to the setup method.

when(suppressor.buildUselessSuppressionBugInstance()).thenReturn(uselessSuppressionBugInstance);

Sorry I'm still lost, I don't see duplications for that line in SuppressionMatcherMockedTest

This ultimately doesn't give any more information than using assertTrue. If possible the error message should say more about the bug value.

I'm not sure how to extract the reason why the instance was matched or not, I think the test is fine like that

Perhaps this message could be adjusted to make it clear why the annotation is no longer needed, ie the code no longer contains that bug type.

Any suggestion? There might be a lot of reason why that suppression annotation was added and why it is now unnecessary

Just something to the effect that the the bug type is no longer raised by that code.

I've expanded the message for these unnecessary suppressions, let me know if that could be improved!