Comments on: should I worry about the unexpected?

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!

By: Tomek Kaczanowski

Tomek Kaczanowski — Sun, 13 Jul 2008 20:47:02 +0000

“and other method on the reader should be called”
you probably meant:
“and NO other method on the reader should be called”

cheers
Tomek Kaczanowski