As somebody relatively new and starting out in test automation, I tried to search for a beginner-friendly explanation of concepts of what on earth is stubbing, mocking and faking. Most definitions are technical as it is used in unit testing or test driven development (TDD).
If anyone has a better example or clearer understanding, please contribute to this thread.
Thank you.
From what Iāve gathered:
Test Double as the generic term for any kind of pretend object used in place of a real object for testing purposes. The name comes from the notion of a Stunt Double in movies.
Mocks and stubs are techniques that are used at the boundaries of the code under test.
Mocks are objects pre-programmed with expectations which form a specification of the calls they are expected to receive.
There is a difference in that the stub uses state verification while the mock uses behaviour verification.
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).
That was a great start @celinetester. Everything I search for takes me to the same article. Iāve been perusing it for awhile, re-reading a bit, trying to understand.
You say:
Mocks are objects pre-programmed with expectations which form a specification of the calls they are expected to receive.
There is a difference in that the stub uses state verification while the mock uses behaviour verification.
So I realized I didnāt know the difference between state verification and behavior verification. So I came across this article, appropriately titled State vs Behaviour Verification, by Santiago Palladino, which also refers back to the same article by Martin Fowler we started with.
He says:
In state verification you have the object under testing perform a certain operation, after being supplied with all necessary collaborators. When it ends, you examine the state of the object and/or the collaborators, and verify it is the expected one.
In behaviour verification, on the other hand, you specify exactly which methods are to be invoked on the collaborators by the SUT, thus verifying not that the ending state is correct, but that the sequence of steps performed was correct.
He gives an example with a User Mail notifier service (the system under test) which pulls from a user repository and sends mail using a Mail Service.
The example includes some code and I am not 100% there yet in trying to decipher the difference, so I think this will take me more reading to understand. I also found an article Why I Donāt Like Mocks, and what I can gather about state vs. behavior testing is that the former is more general, and possibly less brittle.
I would love to see a non-code example, i.e. an IRL example of testing a piece of hardware, an object, a dinner plateā¦I donāt care. Just something I could get my head around!
Exactly. I was also searching for non-code and simple worded examples. I came across a coffee-making analogy in Youtube but still having it explained in source code makes it more intimidating. Too advanced for me!
Fake
A fake is a class that you can use instead of actual line of business code
Stub
Stubs are objects āthat provide canned answers to calls made during the test.ā This might seem the same as the fake but the biggest difference is that a mocking framework like JustMock can be used to create the stub in the test, providing the necessary scaffolding for the system under test in very little code.
Mock describes special objects that mimic real objects for testing
Mock acts as collaborators and are subject to behavioral modification. These collaborators will help you achieve your desired unit-testing goal for a given system and a controlled set of inputs. This is achieved by having the mock object stand in for the real object and returning data you have specified.
Mock brings all of the benefits of stubs plus the ability to specify behavior
A good source that gives particular examples to explain about these definition:
Generically, though this seems to be fairly simple from the outset, it was enlightening to slightly deep dive to understand the actual difference between Fake, Stubs and Mocks.
Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production
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.
I try to simplify by using : Mock and Stub. I use Mock when itās an object that returns a value that is set to the tested class. I use Stub to mimic an Interface or Abstract class to be tested. In fact, it doesnāt really matter what you call it, they are all classes that arenāt used in production, and are used as utility classes for testing.
Fakes
A fake is a class that you can use instead of actual line of business code. This code contains no real business functionality; it is hard coded to return 5. However, it does provide two important benefits:
It allows you to write your first unit test.
It eliminates the need for a real Login Service, isolating dependent code from integration issues.
Stubs
Martin Fowler defines Stubs as objects āthat provide canned answers to calls made during the test.ā This might seem the same as the fake written above, but the biggest difference is that a mocking framework like JustMock can be used to create the stub in the test, providing the necessary scaffolding for the system under test in very little code.
Mocks
Mocks bring all of the benefits of stubs plus the ability to specify behavior. To demonstrate this, I will add behavior checking to the test. The first change is to verify that the arranged method was actually called. Using JustMock, this will require some minor changes to the test.