MockitoHamcrest#argThat does not allow "super" matchers

[spjoe]

IMHO to really follow the hamcrest matchers design philosophy the argThat interface should look like this: public static <T> T argThat(Matcher<? super T> matcher), but unfortunately it is

mockito/src/main/java/org/mockito/hamcrest/MockitoHamcrest.java

Line 60 in 68bc593

public static <T> T argThat(Matcher<T> matcher) {

this change would allow a statement like the following:
verify(mock).aMethod(argThat(nullValue()))

I see that the default value is derived from the concrete matcher type, which of course would not work anymore. To circumvent this problem, it would be possible to provide a overload for primitives types.

Or provide a new argThat method, for example argThatSuper which always returns null, but of course would not work for primitive types. Than the existing argThat would keep its behavior.

[TimvdLippe]

Rather than making changes to MockitoHamcrest, I think our stance is that we are deprecating it. I will send a PR to do that instead. Users should use ArgumentMatchers.argThat instead.

Note that

mockito/src/main/java/org/mockito/ArgumentMatchers.java

Lines 1204 to 1207 in 68bc593

	public static <T> T argThat(ArgumentMatcher<T> matcher) {
	reportMatcher(matcher);
	return null;
	}

probably has the same issue? If so, feel free to send a PR to update the definition and add regression tests.

[spjoe]

Thanks for the fast response @TimvdLippe

I am very sorry to hear that hamcrest matcher support may get deprecated :-(

With the hamcrest matcher support in mockito it was very easy to share matcher implantations over multiple usecases.

For example I use the same matcher in:

• mockito verify
• junit assertThat
• awaitility until

For me dropping the support would mean to rewrite (and maintain) a tone of matchers as ArgumentMatcher.

Please do not drop Hamcrest Matcher support.

Best Regards,
spjoe

[TimvdLippe]

We are keeping this deprecated, but won't delete it for now.