What is wrong with Stubs for unit testing?

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 开发者_Python百科instead of mocks (like Rhinomock etc)? (using Fowler's taxonomy)

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

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.

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.

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.

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.

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.