Suppor scalamock-like syntax and implicit verification? about mockito-scala HOT 7 CLOSED

Hi @Krever
It sounds quite cool, extension methods was something a was thinking how to solve
What I don't get is what you mention about type inference, I never had issues with it using the standard mockito syntax, could you please provide a code snippet that shows the issue?

I agree with the verbosity of the verifications, and it would be great to find a way of simplifying them

Please do share the PoC, I'd more than happy to work with you in adding more and better features to the library

from mockito-scala.

Here is the link to the impl: https://gitlab.com/w-pitula/mockito4s
It's on gitlab cause I don't want to claim rather good name at this stage and confuse people.
It's rather simple but let me know if anything needs more explanation. We could also talk on gitter if a more dynamic form of communication is required.

What I don't get is what you mention about type inference, I never had issues with it using the standard mockito syntax, could you please provide a code snippet that shows the issue?

This is my bad, I was not clear enough. Original mockito syntax doesnt suffer from significant type inference problems. The only one I know is that any[T] is inferred to be any[Nothing] in many cases but I have not dealt with that in any way and I dont even have the example to prove it really happens.

The type inference problems show only when we want to introduce syntax similar to scala mock where we detach function call from its arguments like

(mock.method _).expects // scalamock
mock.expectsCall(_.method _) //my proposal

This detachment is required because mockito uses different ways to trigger setup and verification (to setup we call when(mock.method(args)), to veirfy we call verify(mock).method(args).

With simple methods this kind of syntax it works well, but breaks in at least these 2 cases:

• when there are multiple arguments lists (especially implicits)
• when there are method overloads

In such a case one needs to provide types of all arguments so the compiler knows which extact method we want to call. To overcome this I propose the second syntax in which we specify arguments first and based on that compiler can successfully infer the method.

You can take a look into test to see how the syntax works. One limitation is that to get proper type inference in some case we use overload so methods have names like expects0, expects1 and so on. I find it an acceptable compromise as I much more often change type signatures then function arity.

Additional comments: maybe it can be improved by using macros. I wanted to PoC sth very quickly and my experience with macros is rather limited, so all the "lib" is written in pure scala.

One more this that I reminded mysefl after looking into codebase: I originally planned to allow user to mix matchers with direct arguments passing (like method(1, any[String]). AFAIK this triggers error in mockito and should be quite easy to achieve by simply checking the type of each argument and wrap it in eq matcher if necessary.

from mockito-scala.

All right, I'm taking a look at the code

In the meantime, it's worth to note 2 things
a) you're using Mockito 1.x which had several shortcomings to play with scala
b) any[T] from ArgumentsMatchersSugar solves the type inference anyway (partially by wrapping the call with a Scala call, and partially because it uses Mockito 2.x)

I still think that the syntax you propose could help with other scenarios like auto-verification, but I don't think it's necessary for the sake of type inference

from mockito-scala.

@Krever, thank you for feedback and suggestions!

The implicit verification is available with Mockito today when "strict stubs" are used. Have you seen this feature?

from mockito-scala.

No, apparently I have not, thanks! It feels like I might have missed a lot of mockito development.

Nevertheless, this looks awesome and much simpler then the workaround I came up with. It seems that for scala users (who typically use specs2 or scala test, not junit) MockitoSession is a way to go, is that correct?

from mockito-scala.

@mockitoguy Thanks for the input!
@Krever do you want to create different issues for each one of the features you think are missing so we can tackle them one by one? also feel free to submit PRs if you have a working implementation for any of them already

from mockito-scala.

@bbonanno It feels like all the necessary features are already available. I will check it out in practice and create new issues if anything pops up.

The only feature I can think of is integration with testing frameworks to make enabling strict stubs easier. But its a completely separate thing from this issue.

Thank you guys for all your help!

from mockito-scala.