Introduce functional interfaces to improve Java 8 utilisation of Mockito 2

There are two places where this would be very useful:

1. Custom matchers - used with argThat
2. Custom answers - for situations where you would normally create a subclass of Answer<T>

Some ideas here - https://solidsoft.wordpress.com/2015/06/30/more-compact-mockito-with-java-8-lambda-expressions-and-mockito-java8-add-ons/ - have proposed Java 8 specific extensions outside of mockito, but a small modification to mockito itself, usable by Java 8 but not dependent on it, would be sufficient to get a lot of benefit.

Example - if I wanted to check that the object passed to something had a child with the right value I should be able to write

verify(mock, times(1)).someMethod(
    argThat(input -> input.getChild().getName().equals("Jim")));

Or if I wanted to answer a request

doAnswer(answer(
    string -> string.length()
)).when(mock).execute(anyString());

I will be submitting a pull request to demonstrate these capabilities

[ChristianSchwarz]

@ashleyfrieze What do you think about adding doAnswer(AnswerXXX answer) overloads to the class Mockito?

This would eliminate the need of the answer(…) wapper function.

doAnswer(answer((x,y)->x*y)) vs . doAnswer((x,y)->x*y)

[ashleyfrieze]

Thanks for the comment. I was feeling a bit ignored 😃

The answer is that these are harder to use than the change I’m proposing.

In the case of the boiler plate

invocation.getArgumentAt(0, String.class).length()

My proposal provides a wrapper that can infer all the types and avoid you having to manipulate the invocation object directly.

In the case of the argument matcher, I took the code which I think was probably made that way to comply with something from Hamcrest, which uses Object as the input parameter to the ArgumentMatcher<T> rather than T and just made it more strongly typed. This again reduces the need for boilerplate.