Add back InvocationOnMock.getArgument<T>(int, Class<T>)

[TimvdLippe]

In #365 we replaced the existing getArgumentAt<T>(int, Class<T>) API with the current getArgument(int) API. However, when integrating this change within Google, we ran into numerous issues.

An example:

invocation.getArgumentAt(0, Runnable.class).run()

gets rewritten to

invocation.getArgument(0).run()

This does not compile, as the generic parameter is erasured to Object and thus does not have the run method.

Therefore, I would propose adding back an overload to getArgument that allows you to specify the Class. In general, users would not need this inside a variable assignment, but do need it in all other cases.

[TimvdLippe]

For more information see the error-prone bugpattern: https://errorprone.info/bugpattern/TypeParameterUnusedInFormals

[TimvdLippe]

@mockitoguy WDYT? I think it makes sense to have a simple API for local assignments or in return statements, but we would still need the Class to be explicit.

[mockitoguy]

Looking...

[mockitoguy]

Good idea! Few suggestions:

• document clearly the use case in the new method (compact, readable tests / one-liner invocations).
• add NotExtensible annotation to InvocationOnMock

Nice catch.

[TimvdLippe]

Awesome, thanks for the quick response! Will open a PR today 😄

[Stephan202]

Instead of using the reintroduced getArgument<T>(int, Class<T>), IIUC the issue described above can also be solved as follows:

invocation.<Runnable>getArgument(0).run()

That's admittedly less obvious, but does keep the API smaller. Has this been considered?

[TimvdLippe]

While that does work as well, I think consistency with the old API as well as the readability of the former vs the latter would still lead me to conclude that reintroducing is the appropriate solution.