What is wrong with Stubs for unit testing?

Question

I just watched this funny YouTube Video about unit testing (it's Hitler with fake subtitles chewing out his team for not doing good unit tests--skip it if you're humor impaired) where stubs get roundly criticized. But I don't understand what wrong with stubs.

I haven't started using a mocking framework and I haven't started feeling the pain from not using one.

Am I in for a world a hurt sometime down the line, having chosen handwritten stubs and fakes instead of mocks (like Rhinomock etc)? (using Fowler's taxonomy)

What are the considerations for picking between a mock and handwritten stub?

Kiley

You owe it to yourself using a mocking framework (I use rhino). There are a lot of things they will do to make your TDD life easier. – Furriery

Answer 1

There is nothing wrong with stubs, there is room for stubs, mocks... and spies. All are "test doubles", but with different purposes as explained in Mocks and Stubs aren't Spies:

[...] Before moving on, I'd like to clarify and define some terms in use here, which I originally discovered in Gerard Meszaros' xUnit Patterns book.

• A Dummy Object is a placeholder object passed to the system under test but never used.
• A Test Stub provides the system under test with indirect input
• A Test Spy provides a way to verify that the system under test performed the correct indirect output
• A Mock Object provides the system under test with both indirect input and a way to verify indirect output

[...] And you can let this handy chart guide your decisions:

PS: Mockito - The New Mock Framework on the Block is worth the read too.

Cavetto

+0.5 for the chart, +0.5 for the link – Stringpiece

-1 for the chart, it's basically wrong. Mocks can fail at assertions, they can be easier to maintain, and are pretty much easier to use all around. I think the chart may be outdated or against an old mocking framework or a framework in an older language/version of Java. (Not really voting -1, but that chart is bad) – Bedsore

Answer 2

I use the following terminology (introduced by Roy Osherove, the author of the Art of Unit-Testing):

A fake is called a stub if you tell it to fake something in case a method is called with such and such parameters. But if you also verify that such call actually took place or took place exactly N times, then such fake is called a mock. In short. a fake is a stub unless you call Verify() on it and then it's a mock.

Obviously, you will need to use stubs in some cases and mocks in others. So, criticizing stubs roundly is probably wrong and using stubs exclusively is probably wrong as well.

If you haven't started using a mocking framework (alternative term: isolation framework), you should keep an eye on them and reevaluate your options frequently. I went from manual mocks to NMock2 to Moq very quickly. Here's an interesting poll of programmers that shows what they use. Manual mocks/stubs are in the minority, but aren't that uncommon.

Rudbeckia

+1 for the Art of Unit Testing (good book) and for Moq (good tool). – Tuberculate

Answer 3

Mocks are just a lot easier to throw in. They are a real instance of your class, pre-stubbed with the ability to override the action of any method with minimal boilerplate.

There are lots of little considerations such as: If you don't want to deal with any of the methods, you can either have it act as a no-op or fail the test--your choice--but either way virtually no code.

How much boilerplate do you get when you stub out a class? How do you handle it if your class is final? Do you play tricks to get your stub on the classpath first, or do you use different source?

I recommend just starting with the mocks--It's easier all around.

Bedsore

Answer 4

There is nothing wrong with using stubs instead of mocks.

If you want to get technical, mocks are "smart" objects with expectations that can be verified. Stubs are dummy objects that return preset values. See Mocks Aren't Stubs.

But many people (myself included) prefer to do state testing with stubs rather than behavior testing with mocks. You inject a stub into the class under test, you call a method, then you check the state of the class under test. It tends to make for less brittle tests than asserting that the class's internals called method X of a mock object with argument Y.

I don't think you're in for a world of hurt. If you haven't started feeling the pain, you probably don't need an isolation/mocking framework yet. When and if you do, having handwritten stubs/fakes around isn't going to hurt anything.

If you have a lot of interfaces, or if your interfaces have a lot of methods, an isolation/mocking framework can save a lot of time over hand-coding stubs.

I like Moq a lot; I find it easier to use than Rhino Mocks for creating stubs.

Tuberculate

Answer 5

Mocks and stubs is used to achieve a real unit test. You just mock all the dependencies, and unit test your class in isolation.

I'm currently using MOQ for mocking and stubbing.

Schonfield