You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given that there's an InOrder.verifyNoMoreInteractions() I suppose the usefulness of exhaustive in-order testing (i.e. verifying that calls have been made in the expected order and that no additional calls have been made) is appreciated. If not, please consider the example of a class that is configured with a builder (interface) object and given a certain input emits method calls to the builder object (e.g. some kind of streaming parser emitting parsing events). In that case it is important to test that for a given input calls are emitted in the right order and that only those calls are emitted.
Two issues make working with those tests a bit tedious:
An additional call is only reported at the end (when verifyNoMoreInteractions() is invoked). It would be much more helpful, if the exhaustive mode could be declared at the beginning (e.g. via an additional inOrder() argument or a InOrder setter method). Then an unexpected call could be reported at the point where a different call was expected. This would safe a bit of debugging to track those down.
If an expected call is made with incorrect arguments -- e.g. mock.a(); mock.b(1); instead of mock.a(); mock.b(2); -- then we currently get an invocation order failure Wanted but not invoked: mock.b(2) ... anywhere AFTER the following interaction: mock.a().... Alas it doesn't tell us that mock.b(1) was invoked instead. Again, declaring an exhaustive mode first would allow reporting the unexpected actual (besides the expected) call at that point. I suppose my simple example could be handled even without such a mode, but it is easy to think of cases where the mismatch would only be detected later (in case of repeated calls to the same methods) or at the very end (as above).
To sum it up: It would be very helpful to be able to tell InOrder that exhaustive testing is intended, so that actual and expected call could both be reported immediately when they differ.
The text was updated successfully, but these errors were encountered:
I just noticed that InOrder.verifyNoMoreInteractions() doesn't what I thought it did and using Mockito.verifyNoMoreInteractions() reports the list of all calls made, which makes the first issue I listed moot. The second one still stands, though.
Basically, it boils down to improving the verification error message emitted from the InOrder.verifyNoMoreInteractions() It needs to better handle the use case of the argument mismatch.
Given that there's an
InOrder.verifyNoMoreInteractions()
I suppose the usefulness of exhaustive in-order testing (i.e. verifying that calls have been made in the expected order and that no additional calls have been made) is appreciated. If not, please consider the example of a class that is configured with a builder (interface) object and given a certain input emits method calls to the builder object (e.g. some kind of streaming parser emitting parsing events). In that case it is important to test that for a given input calls are emitted in the right order and that only those calls are emitted.Two issues make working with those tests a bit tedious:
verifyNoMoreInteractions()
is invoked). It would be much more helpful, if the exhaustive mode could be declared at the beginning (e.g. via an additionalinOrder()
argument or aInOrder
setter method). Then an unexpected call could be reported at the point where a different call was expected. This would safe a bit of debugging to track those down.mock.a(); mock.b(1);
instead ofmock.a(); mock.b(2);
-- then we currently get an invocation order failureWanted but not invoked: mock.b(2) ... anywhere AFTER the following interaction: mock.a()...
. Alas it doesn't tell us thatmock.b(1)
was invoked instead. Again, declaring an exhaustive mode first would allow reporting the unexpected actual (besides the expected) call at that point. I suppose my simple example could be handled even without such a mode, but it is easy to think of cases where the mismatch would only be detected later (in case of repeated calls to the same methods) or at the very end (as above).To sum it up: It would be very helpful to be able to tell
InOrder
that exhaustive testing is intended, so that actual and expected call could both be reported immediately when they differ.The text was updated successfully, but these errors were encountered: