Comments on: should I worry about the unexpected?

By: Uberto

Uberto — Tue, 01 Mar 2011 11:32:58 +0000

;)

Anyway I have to correct myself, I’m putting a lot of verifyNoMoreInteractions() in my tests and I’m still found them useful.

I’m working with GOOS style, only finding mockito syntax nicer than Jmock. This means I mock mostly interfaces, not classes.

In your examples I find #3 and #4 wrong because I don’t want to compare status but only to tests iterations between objects.

Also if in my tests I feel I need too many verifies, that’s a smell my objects either has too many resp or need a new interface (I in SOLID).

By: szczepiq

szczepiq — Mon, 28 Feb 2011 18:12:58 +0000

Hmmm… could work given I also tell the user that “maybe you don’t really need verifyNoMore here?”.

It’s best to suggest features in our tracker.

Cheers!

By: Uberto

Uberto — Sat, 19 Feb 2011 10:42:21 +0000

Hi I really like some kind of setup like “verifyNoMoreTell = true” for all my tests.
Also using the simple rule that “void return methods are Tell” would be useful.

Anyway atm I’m not putting a lot of verifyNoMoreInteractions in my tests but I find it very useful when I need to start testing a class which wasn’t under test before.

Would be very nice if there could be a way to let Mockito print out the missing verify, something like:

org.mockito.exceptions.verification.NoInteractionsWanted:
No interactions wanted here:
-> at xxx.java:42
But found this interaction:
-> at yyy.java:84

maybe you forgot to add a verify?
-> verify(xxx).zzz(any());

I’m also willing to contribute with the code if there’s interest.

By: Anonymous

Anonymous — Tue, 30 Jun 2009 10:32:41 +0000

> If I were about writing mockito again, I would definitely
> consider making verifyNoMoreInteractions() assert only ‘tell’
> interactions. Any ideas how to fix it without serious impact
> on backwards compatibility?

How ’bout: verifyAsk, verifyTell, and verifyNoMoreTell?!?

BTW: Both tests in your example will fail ;)

By: Tom De Wolf

Tom De Wolf — Wed, 22 Oct 2008 10:15:39 +0000

I agree that testing the unexpected is important, but that frameworks should not do this by default. You need the choice because sometimes it is not important.

By: szczepiq

szczepiq — Tue, 21 Oct 2008 20:37:12 +0000

>Then maybe testing the unexpected IS important. It depends on the case at hand I think.

That’s true, maybe testing the unexpected is important. However state testing has been here for years and I haven’t noticed anyone complaining on the fact that junit does not check for unexpected. You can achieve it obviously but it is not “in the framework”.

The way state testing works just feels right to me. If I want to test the unexpected I will be extra explicit and make my test richer. Mocking is different: testing the unexpected is turned on by default. Many times I have to be extra explicit and ignore irrelevant interactions. It makes my tests noisier, not richer…

By: Tom De Wolf

Tom De Wolf — Fri, 17 Oct 2008 10:31:30 +0000

writing verifyNoMoreInteractions to only assert ‘tell’ interactions is difficult because you cannot assume that every method written is only an ‘ask’ or ‘tell’. Any system includes methods that have a side effect and also return information. Thus a combination of ‘ask’ and ‘tell’ :-) Any void method is only a ‘tell’ method but not any returning method is only an ‘ask’ method. But it should be in the ideal case.

considering upexpected changes to other public state: you can an should write tests that only test changes to certain public state. However, I think that, for each public state there should be one or more tests that test the methods changing that public state.

Still, one could have a situation where an unexpected change to other public states than the state under test indicates a bug. Then maybe testing the unexpected IS important. It depends on the case at hand I think.

By: szczepiq

szczepiq — Thu, 16 Oct 2008 23:11:51 +0000

What about a situation where an object does not have any ‘private’ state? Still, I would like to test only certain public state without worrying about unexpected changes to other public state.

>Note, I say ‘maybe’ use verifyNoInteractions because if you consider the difference >between ‘asking’ and ‘telling’

Very true. If I were about writing mockito again, I would definitely consider making verifyNoMoreInteractions() assert only ‘tell’ interactions. Any ideas how to fix it without serious impact on backwards compatibility? :)

By: Tom De Wolf

Tom De Wolf — Thu, 16 Oct 2008 11:08:08 +0000

I share the thought that we should not write verifyNoInteractions everywhere on every mock. But I do see an important difference between state testing and interaction testing.

Consider a class UnitUnderTest which has state and interacts with AnotherUnit.

- state testing: we only test state which is accessible in the interface of UnitUnderTest. Internal state, never made public is not to be tested. Hence, state is closely related to encapsulation. And indeed, we do not have to test that for UnitUnderTest no unexpected changes are made to private state.

- interaction testing: in this case interacting with AnotherUnit implies you ask to do some actions to that unit. Thus this affects the behaviour of the application + it crosses the encapsulation boundary. Therefore it should be tested AND maybe also tested that no other interactions happen with that unit. This because other interaction trigger extra behaviour which is not wanted according to the test.

Note, I say ‘maybe’ use verifyNoInteractions because if you consider the difference between ‘asking’ and ‘telling’ (see your other blog entry) then clearly only the telling interactions should be verified and if UnitUnderTest also asks things to AnotherUnit then verifyNoMoreInteractions would imply to also verify the ‘asking’ interactions which we want to avoid.

By: Hamlet D'Arcy

Hamlet D'Arcy — Wed, 16 Jul 2008 16:54:04 +0000

Simply put: verifying expectations leads to overspecified and fragile tests. In practice, I’m just as likely to delete and rewrite a test case with failing expectation as I am to update them to work correctly. When I hit someone else’s failing test cases that verify every expectation possible, it simply isn’t worth my time to try to fix them.

As for the synopsis of “worrying about unexpected may NOT be such a good friend of TDD”… Heck, it isn’t even a good friend of maintainability!

My opinion: write side effect free code. Pass in stubs if you must, reverting to spies and mocks only when necessary… and please verify only the things you really care about!