Is this a good simplification of fake object types?

Question

With every unit testing text I get my hands on comes a little different terminology and more or less different definitions of various fake object types. I find that a lot of this differentiation is too theoretical to be of value in daily practice and I tend to simplify it all to mocks and stubs in the following way.

Stubs

• are fake objects which replace and supplement dependencies of the unit under test to make the testing of the unit possible
• should not break the test

Mocks

• are fake objects with set expectations about how the unit under test should behave and are asserted to verify these expectations
• can break the test

Is this a good way to simplify or am I missing some important points here?

Is it enough to only talk about stubs and mocks, or are there some other, equally important, base fake types that we work with regularly?

I don't need to consider any other fakes and these simple definitions are enough for me while working with unit tests on daily basis, but this can be because unit testing is not being taken too seriously at my environment. So I have this feeling that I may not be getting it right and would like to clear up my understanding before I grow some bad habits.

Answer 1

Your summaries are fine.

Alas, I don't think they'll help you avoid confusion when you talk to other people. If people in a conversation are using the words differently, you'll have to sort out the meanings, and injecting my own summaries never seems to help. Sorting the meanings is always a negotiation.

Fortunately, for most conversations it isn't necessary to make the distinctions (either the subtle ones or the gross ones) among various kinds of test doubles.

For those cases where the distinctions are useful, I recommend the taxonomy of "test doubles" that Gerard Meszaros describes in his popular and very useful book xUnit Test Patterns, pp 133–139. Gerard offers these terms, with definitions:

• Dummy Object: an object that is passed but never actually used.
• Test Stub: an object used to inject indirect inputs into the SUT—that is, an object from which the SUT obtains inputs.
• Mock Object: an object that compares actual calls received against defined expectations.
• Fake Object: an object that replaces the functionality of a real collaborator with an alternative implementation for test purposes.

Note that these are my summaries of Gerard's definitions. I recommend going to the source. The book is awesome. And given the relative popularity and widespread awareness of Gerard's taxonomy, it's as close to an authoritative standard as you're ever likely to find.

These days, I prefer not to bother trying to fit various test doubles into categories. Instead, I focus on what role I want the double to fulfill in my tests. See my blog post on the subject: "The Unbearable Lightness of Faking". And please forgive my non-standard use of the term faking.

Answer 2

I infer from your last paragraph that you started automated unit testing recently and you are unsure whether you are practicing it correctly. You are unable to seek advise from anyone in your environment, and even after consulting some books, you worry that you may develop bad habits.

I believe your stubs/mocks dichotomy is as good as it needs to be. I have seen bloggers who advocate lots of stubbing/mocking. In my work, stubs/mocks are usually more trouble than they are worth, so I rarely use them. Whether you need them will depend upon the kind of software you are trying to test. Before asking, "Which should I use here: a stub or a mock?", first ask, "Can I get by without a stub/mock?"

You can find more advice on mocks at https://sqa.stackexchange.com/search?q=mock.

Regardless of what you do, you will develop bad habits. We all do, because it is part of the learning process. A bad habit for an experienced practitioner may even be a good habit for a beginner. The way to overcome bad habits is to pay attention to what you practice.

Now go write some tests.

(Edit)

It's been a few years since I wrote that answer and I've changed my mind about whether mocks are a good use of time. A good mocking framework can let you write tests that are simpler and more reliable than they would be without mocks.

Answer 3

I like how UncleBob brings it, he names them test doubles.

Is there a formal name for these test objects?

Yes, they are called "Test Doubles"[1].

To understand the different test doubles I suggest you read: The following is a conversation around mocking. (After reading this I thought now i think i understand it.)

He then comes up with five types:

• Dummies
• Stubs
• Spies
• Mocks
• Fakes

But instead quoting definitions here, read the article, its worth your time :)