java - Is it unnecessary to verify the same methods as the methods being mocked in Mockito? -

i see same methods being verified methods being mocked in mockito (example below). there added benefit call mockito.verify() in these cases?

//mock method fooservice fs = mock(fooservice.class); when(fs.getfoo()).thenreturn("foo");  //method under test fs.dosomething();  //verify method verify(fs).getfoo(); 

the method should fail if fs.getfoo() not called. why call verify? see benefit if need use argumentcaptor in verify assert parameters; besides argumentcaptor case, unnecessary?

the mockito documentation repeatedly says redundant. appears verbatim both in verify(t)'s javadoc multiple single-line comments in code block in mockito's main class javadoc section 2:

although possible verify stubbed invocation, it's redundant. if code cares get(0) returns, else breaks (often before verify() gets executed). if code doesn't care get(0) returns, should not stubbed. not convinced? see here.

note linked article, "asking , telling", written mockito originator szczepan faber , can considered authoritative document in mockito's design. excerpt post:

do have repeat same expression? after all, stubbed interactions verified implicitly. execution flow of own code completely free. aaron jensen noticed that:

if you’re verifying don’t need stub unless of course method returns critical flow of test (or code), in case don’t need verify, because flow have verified.

just recap: there no repeated code.

but if interesting interaction shares characteristic of both asking , telling? have repeat interactions in stub() , verify()? end duplicated code? not really. in practice: if stub verified free, i don’t verify. if verify don’t care return value, i don’t stub. either way, i don’t repeat myself. in theory though, can imagine rare case verify stubbed interaction, example make sure stubbed interaction happened n times. different aspect of behavior , apparently interesting one. therefore want explicit , happy sacrifice 1 line of code…

overall, mockito's design allow tests flexible possible, coding not implementation instead spec of method you're testing. though you'll see method call part of function's spec ("submits rpc server" or "calls passed logincallback immediately"), it's more you'll want validate postconditions can infer stubs: checking getfoo called isn't part of spec long stubbed getfoo return "foo" , data store contains single object corresponding property set "foo".

---

in short, considered mockito style explicitly verify interactions can't implied well-crafted stubs , postcondition assertions. may calls otherwise-unmeasurable side effects—logging code, thread executors, argumentcaptors, multiple method calls, callback functions—but should not applied stubbed interactions.