@OP Because there is no difference. This article, as much as loved by the community, is - with all due respect - making everything unnecessary confusing by adding additional meaning to words that are easy to understand otherwise and by making things unnecessary complicated. Mock is just a mock, something that runs fake business logic instead of real one. Checking for behavior in the end is your choice, but it is still a mock. Or whatever you want to call it, but make it ONE. Do not split a hairs. Keep it simple, so people can understand your concept easily - which above article does fail with.
– wstJun 29 '16 at 2:30

3

"Classification between mocks, fakes, and stubs is highly inconsistent across the literature." With many citations. Still one of my favorite Wikipedia quotes - if such a thing exists :) en.wikipedia.org/wiki/Mock_object
– JD.Sep 22 '16 at 15:47

32 Answers
32

I believe the biggest distinction is that a stub you have already written with predetermined behavior. So you would have a class that implements the dependency (abstract class or interface most likely) you are faking for testing purposes and the methods would just be stubbed out with set responses. They would not do anything fancy and you would have already written the stubbed code for it outside of your test.

Mock

A mock is something that as part of your test you have to setup with your expectations. A mock is not setup in a predetermined way so you have code that does it in your test. Mocks in a way are determined at runtime since the code that sets the expectations has to run before they do anything.

Difference

Tests written with mocks usually follow an initialize -> set expectations -> exercise -> verify pattern to testing. While the pre-written stub would follow an initialize -> exercise -> verify.

Similarity

The purpose of both is to eliminate testing all the dependencies of a class or function so your tests are more focused and simpler in what they are trying to prove.

Foreword

Reference

Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.

Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).

Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.

Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

Style

Mocks vs Stubs = Behavioral testing vs State testing

Principle

According to the principle of Test only one thing per test, there may be several stubs in one test, but generally there is only one mock.

Lifecycle

Test lifecycle with stubs:

Setup - Prepare object that is being tested and its stubs collaborators.

Exercise - Test the functionality.

Verify state - Use asserts to check object's state.

Teardown - Clean up resources.

Test lifecycle with mocks:

Setup data - Prepare object that is being tested.

Setup expectations - Prepare expectations in mock that is being used by primary object.

Exercise - Test the functionality.

Verify expectations - Verify that correct methods has been invoked in mock.

Verify state - Use asserts to check object's state.

Teardown - Clean up resources.

Summary

Both mocks and stubs testing give an answer for the question: What is the result?

Testing with mocks are also interested in: How the result has been achieved?

From what you wrote I can tell that mocks = stubs + expectations and verifications, because mocks "provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test" (same as stubs). And example that Fowler showed as example of a stub is actually example of a spy! That means that a mock is a stub, and a spy is a stub. And a stub is just an object that have several working methods. That also explains why Mockito deprecated stub() method.
– kolobokJul 8 '18 at 20:35

I don't think a mock is a stub. Mocks are used to assert and should never return data, stubs are used to return data and should never assert.
– dave1010Aug 3 '15 at 14:00

1

@dave1010 Mocks most definitely can return data or even throw an exception. They should do so in response to the params passed into them.
– TrentonAug 17 '15 at 18:33

2

@trenton if an object returns or throws based on data passed in then it's a fake, not a mock. Stubs test how your SUT handles receiving messages, mocks test how your SUT sends messages. Mixing up the 2 is likely to lead to bad OO design.
– dave1010Aug 24 '15 at 7:41

1

Can you provide an example code of a STUB and a mock (with minimum lines of code)? Thanks
– vsyncNov 9 '15 at 18:48

Example: If you're testing a method of a class which requires many mandatory parameters in a constructor which have no effect on your test, then you may create dummy objects for the purpose of creating new instances of a class.

Fake - create a test implementation of a class which may have a dependency on some external infrastructure. (It's good practice that your unit test does NOT actually interact with external infrastructure.)

Example: Create fake implementation for accessing a database, replace it with in-memory collection.

Stub - override methods to return hard-coded values, also referred to as state-based.

Example: Your test class depends on a method Calculate() taking 5 minutes to complete. Rather than wait for 5 minutes you can replace its real implementation with stub that returns hard-coded values; taking only a small fraction of the time.

Mock - very similar to Stub but interaction-based rather than state-based. This means you don't expect from Mock to return some value, but to assume that specific order of method calls are made.

I think the simplest and clearer answer about this question is given from Roy Osherove in his book The art of Unit Testing (page 85)

The easiest way to tell we’re dealing with a stub is to notice that the stub can never fail the test. The asserts the test uses are always against
the class under test.

On the other hand, the test will use a mock object to verify whether the
test failed or not. [...]

Again, the mock object is the object we use to see if the test failed or not.

That means if you are making assertions against the fake it means you are using the fake as a mock, if you are using the fake only to run the test without assertion over it you are using the fake as a stub.

STUB: The network connection to twitter API is very slow, which make my test slow. I know it will return timelines, so I made a stub simulating HTTP twitter API, so that my test will run it very fast, and I can running the test even I'm offline.

MOCK: I haven't written any of my UI methods yet, and I'm not sure what methods I need to write for my ui object. I hope to know how my controller will collaborate with my ui object by writing the test code.

By writing mock, you discover the objects collaboration relationship by verifying the expectation are met, while stub only simulate the object's behavior.

This is the more clear explanation of the diff between the two, IMO. For stub: the tester take the Stub and use it directly inside the class under test. But for Mock, the tester has to device way how the Mock object will be used. In different cases, it will behave differently. In contrast, stub is not expected to behave differently but is used as it is (meaning returning the same data whenever contacted)
– DexterNov 27 '18 at 5:45

Using a mental model really helped me understand this, rather than all of the explanations and articles, that didn't quite "sink in".

Imagine your kid has a glass plate on the table and he starts playing with it. Now, you're afraid it will break. So, you give him a plastic plate instead. That would be a Mock (same behavior, same interface, "softer" implementation).

Now, say you don't have the plastic replacement, so you explain "If you continue playing with it, it will break!". That's a Stub, you provided a predefined state in advance.

A Dummy would be the fork he didn't even use... and a Spy could be something like providing the same explanation you already used that worked. A Fake would be like lying that a policeman will come if he continues (not sure about the last part :).

A fake is a generic term that can be used to describe either a stub
or a mock object (handwritten or otherwise), because they both look like the
real object.

Whether a fake is a stub or a mock depends on how it’s used in
the current test. If it’s used to check an interaction (asserted against), it’s a
mock object. Otherwise, it’s a stub.

Fakes makes sure test runs smoothly. It means that reader of your future test will understand what will be the behavior of the fake object, without needing to read its source code (without needing to depend on external resource).

You want to test mailService.SendEMail() method, to do that you need to simulate an Exception in you test method, so you just need to create a Fake Stub errorService class to simulate that result, then your test code will be able to test mailService.SendEMail() method. As you see you need to simulate a result which is from an another External Dependency ErrorService class.

Fake: Fakes are objects that have working implementations, but not the same as production one. Such as: in-memory implementation of Data Access Object or Repository.

Stub: Stub is an object that holds predefined data and uses it to answer calls during tests. Such as: an object that needs to grab some data from the database to respond to a method call.

Mocks: Mocks are objects that register calls they receive.
In test assertion, we can verify on Mocks that all expected actions were performed. Such as: a functionality that calls e-mail sending service.
for more just check this.

Stubs are dummy implementations of production code that return canned
results. Mock Objects act as stubs, but also include assertions to
instrument the interactions of the target object with its neighbours.

So, the main differences are:

expectations set on stubs are usually generic, while expectations set on mocks can be more "clever" (e.g. return this on the first call, this on the second etc.).

stubs are mainly used to setup indirect inputs of the SUT, while mocks can be used to test both indirect inputs and indirect outputs of the SUT.

To sum up, while also trying to disperse the confusion from Fowler's article title: mocks are stubs, but they are not only stubs.

I came across this interesting article by UncleBob The Little Mocker. It explains all the terminology in a very easy to understand manner, so its useful for beginners. Martin Fowlers article is a hard read especially for beginners like me.

Stub is dummy implementation done by user in static way mean i.e in Stub writing the implementation code. So it can not handle service definition and dynamic condition, Normally this is done in JUnit framework without using mocking framework.

Mock is also dummy implementation but its implementation done dynamic way by using Mocking frameworks like Mockito. So we can handle condition and service definition as dynamic way i.e. mocks can be created dynamically from code at runtime. So using mock we can implement Stubs dynamically.

Stub helps us to run test. How? It gives values which helps to run test. These values are itself not real and we created these values just to run the test. For example we create a HashMap to give us values which are similar to values in database table. So instead of directly interacting with database we interact with Hashmap.

"So instead of directly interacting with database we interact with Hashmap." ...because whe had no time yet to code the Database-Module, and we could not run the test-code without using the stub. Otherwise the very same Hasmap would be a mock! right?
– Boris DäppenOct 24 '15 at 11:39

I have used python examples in my answer to illustrate the differences.

Stub - Stubbing is a software development technique used to implement methods of classes early in the development life-cycle. They are used commonly as placeholders for implementation of a known interface, where the interface is finalized or known but the implementation is not yet known or finalized. You begin with stubs, which simply means that you only write the definition of a function down and leave the actual code for later. The advantage is that you won't forget methods and you can continue to think about your design while seeing it in code. You can also have your stub return a static response so that the response can be used by other parts of your code immediately. Stub objects provide a valid response, but it's static no matter what input you pass in, you'll always get the same response:

Mock objects are used in mock test cases they validate that certain methods are called on those objects. Mock objects are simulated objects that mimic the behaviour of real objects in controlled ways. You typically creates a mock object to test the behaviour of some other object. Mocks let us simulate resources that are either unavailable or too unwieldy for unit testing.

This is a very basic example that just runs rm and asserts the parameter it was called with. You can use mock with objects not just functions as shown here, and you can also return a value so a mock object can be used to replace a stub for testing.

More on unittest.mock, note in python 2.x mock is not included in unittest but is a downloadable module that can be downloaded via pip (pip install mock).

I have also read "The Art of Unit Testing" by Roy Osherove and I think it would be great if a similar book was written using Python and Python examples. If anyone knows of such a book please do share. Cheers :)

A Stub is an object that implements an interface of a component, but instead of returning what the component would return when called, the stub can be configured to return a value that suits the test. Using stubs a unit test can test if a unit can handle various return values from its collaborator. Using a stub instead of a real collaborator in a unit test could be expressed like this:

unit test --> stub

unit test --> unit --> stub

unit test asserts on results and state of unit

First the unit test creates the stub and configures its return values. Then the unit test creates the unit and sets the stub on it. Now the unit test calls the unit which in turn calls the stub. Finally the unit test makes assertions about the results of the method calls on the unit.

A Mockis like a stub, only it also has methods that make it possible determine what methods where called on the Mock. Using a mock it is thus possible to both test if the unit can handle various return values correctly, and also if the unit uses the collaborator correctly. For instance, you cannot see by the value returned from a dao object whether the data was read from the database using a Statement or a PreparedStatement. Nor can you see if the connection.close() method was called before returning the value. This is possible with mocks. In other words, mocks makes it possible to test a units complete interaction with a collaborator. Not just the collaborator methods that return values used by the unit. Using a mock in a unit test could be expressed like this:

A test subject performs actions in response to certain prompts (function calls) or other stimuli. Here are concrete examples of test situations.

Scenario -- EMT student exam

A student has studied to be an Emergency Medical Technician. Go watch Ian Gallagher in Shameless Season 6, Episode 10 if you are unfamiliar with this test situation.

It is too expensive to find patients with various illnesses for test purposes. Instead we use actors. We ask the test subject (Ian) "you arrive on the scene and the patient is immobilized and unconscious what do you do first?" Ian responds "I check if the scene is safe". And the test instructor says "the scene is safe".

The instructor (and actor) are able to inject arbitrary answers to the test subject's queries.

Here, the instructor (and actor) are a mock. Medical training uses this terminology (e.g. mock code simulation) the same as computer scientists.

Scenario -- register for a website

You are testing Yahoo, a new email service you heard about. In order to sign up, you must provide your birthday and answers to other intrusive questions.

The website requires that you are 21 years or older. So you enter in the value January 1, 1970. It meets the requirements and it saves you from the laborious process of implementing a remember-my-birthday-and-type-it-in workflow.

if you create test objects locally and feed your local service with that, you are using mock object.
this will give a test for the method you implemented in your local service.
it is used to verify behaviors

when you get the test data from the real service provider, though from a test version of interface and get a test version of the object, you are working with stubs
the stub can have logic to accept certain input and give corresponding output to help you perform state verification...