org.mockito.exceptions.misusing.UnfinishedVerificationException

23 views
Skip to first unread message

Stan Rosenberg

unread,
Jan 11, 2021, 1:44:55 PMJan 11
to mockito
Hi,

We recently ran into UnfinishedVerificationException which was rather tricky to track down.  The problem stems from an incorrect usage of the API, namely Mockito.verify which clearly states that `someMethod` is expected to be invoked on the returned mock.  

In our case, it was a closure object (in scala) which was being mocked, resulting in the following specification (using MockitoSugar with scalatest),

verify(resourceProvider, times(3))

Since resourceProvider is typically invoked via (), the user forgot to specify 'apply', i.e.,

verify(resourceProvider, times(3)).apply()

The end result was an unvalidated MockingProgressImpl? because we saw the exception being thrown here [1], except it was an unrelated unit test which triggered it.
Is there a better way to guard against this type of incorrect API usage?
Thanks.

Best,

stan


Fr Jeremy Krieg (Home)

unread,
Jan 13, 2021, 3:29:15 AMJan 13
to moc...@googlegroups.com
Hi stan,

I pray that you are well.

I have a wacky idea.

Perhaps, instead of making this usage an error, we adopt it. Ie, if the object being verified is implementing a functional interface with a single method that takes no arguments ("functionalMethod()"), we let that syntax stand as a shorthand for "verify(myObject, times(n)).functionalMethod()".

Just a thought.

Blessings,
Fr Jeremy

--
You received this message because you are subscribed to the Google Groups "mockito" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mockito+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mockito/364761ae-55b9-4fd5-8d2f-88fd413ec9a6n%40googlegroups.com.

Stan Rosenberg

unread,
Jan 15, 2021, 3:57:47 AMJan 15
to mockito
On Wednesday, January 13, 2021 at 3:29:15 AM UTC-5 jezzy...@gmail.com wrote:
Perhaps, instead of making this usage an error, we adopt it. Ie, if the object being verified is implementing a functional interface with a single method that takes no arguments ("functionalMethod()"), we let that syntax stand as a shorthand for "verify(myObject, times(n)).functionalMethod()".

Indeed, this syntax is arguably more intuitive, especially when myObject implements the Function interface. However, it would require non-trivial changes.  I am not very familiar with mockito's codebase but happy to contribute.  Perhaps, mockito committers could comment on whether this is a good idea; if not, what can we do to prevent the unwanted side-effect.
Reply all
Reply to author
Forward
0 new messages