Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve exhaustive in-order testing #315

Open
weinhold opened this issue Nov 4, 2015 · 2 comments
Open

Improve exhaustive in-order testing #315

weinhold opened this issue Nov 4, 2015 · 2 comments

Comments

@weinhold
Copy link

weinhold commented Nov 4, 2015

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.

@weinhold
Copy link
Author

weinhold commented Nov 4, 2015

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.

@mockitoguy
Copy link
Member

+1

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants