How to make spy assume call all real methods, unless override

[KARR, DAVID]

I'm about to write some tests for a few classes that have too many methods, along with a small number of methods that I'm going to have to mock, so I'm going to have to "spy" it. The annoying thing I see coming is that it looks like if I "spy" my class I'm going to have to write numerous "when(spied.method()).thenCallRealMethod()" calls, except for the small number of methods that I need to mock. I almost wish I could make it assume that it will call all real methods, and then specify the ones I want to mock.

[David Wallace]

You don't need to write the thenCallRealMethod calls.  That's what a spy does by default.

 

But why are you mocking methods in the class that you're going to test?  The whole idea is to mock methods in other classes that it interacts with.

 

Regards,

David.

On Tue, Feb 14, 2012 at 12:14 PM, KARR, DAVID <dk0...@att.com> wrote:

I'm about to write some tests for a few classes that have too many methods, along with a small number of methods that I'm going to have to mock, so I'm going to have to "spy" it.  The annoying thing I see coming is that it looks like if I "spy" my class I'm going to have to write numerous "when(spied.method()).thenCallRealMethod()" calls, except for the small number of methods that I need to mock.  I almost wish I could make it assume that it will call all real methods, and then specify the ones I want to mock.

--
You received this message because you are subscribed to the Google Groups "mockito" group.
To post to this group, send email to moc...@googlegroups.com.
To unsubscribe from this group, send email to mockito+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mockito?hl=en.

[Brice Dutheil]

Hi David,

It's the opposite; spy allows you to spy *real* calls and you stub only the relevant one.

Also it seems you are making a partial mock, it's considered a bad practice. I don't know much more about the context, but you should avoid such test code. Of course unmodifiable legacy code is another story.

Cheers,

-- Brice

On Tue, Feb 14, 2012 at 00:14, KARR, DAVID <dk0...@att.com> wrote:

I'm about to write some tests for a few classes that have too many methods, along with a small number of methods that I'm going to have to mock, so I'm going to have to "spy" it.  The annoying thing I see coming is that it looks like if I "spy" my class I'm going to have to write numerous "when(spied.method()).thenCallRealMethod()" calls, except for the small number of methods that I need to mock.  I almost wish I could make it assume that it will call all real methods, and then specify the ones I want to mock.

[KARR, DAVID]

Thanks.  I got it working. Concerning standard practice, theory is often not reality.

[Brice Dutheil]

Concerning standard practice, theory is often not reality.

Yeah, just like "Don't call System.gc() directly...", or when Robert C Martin aka Uncle Bob is talking about SOLID designs.

There's a reason why we say that. We don't talk about anti-patterns or bad practice just for the fun of a theory. If people didn't apply unit testing or TDD just because some other guys had a theory "hey unit tests are good for your piece of code" then we would live in a different world with even more crappier software.

However, as said there's some edge cases were you can break the line, because you have a very very very good reason to do it.

I'm quite hard line on this matter. Usually when I see that and other anti-patterns, the test code is giving me hint of a test smell, that I should really refactor the code to NOT use these techniques. Imho avoiding anti-patterns and reasonably using patterns favors the emergence of good design in the code.

 

Cheers,

-- Brice