org.mockito.exceptions.misusing.UnfinishedVerificationException

88 wyświetleń
Przejdź do pierwszej nieodczytanej wiadomości

Stan Rosenberg

nieprzeczytany,
11 sty 2021, 13:44:5511.01.2021
do 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)

nieprzeczytany,
13 sty 2021, 03:29:1513.01.2021
do 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

nieprzeczytany,
15 sty 2021, 03:57:4715.01.2021
do 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.
Odpowiedz wszystkim
Odpowiedz autorowi
Przekaż
Nowe wiadomości: 0