30 Days of Automation Testing Day 11- Compare and contrast Mocking,Stubbing and Faking


(Celine) #1

#30daytestingchallenge
#day11of 30daytestingchallenge

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).

Sources:

Mocks Aren’t Stubs

Test Doubles


(David) #2

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!

-Dave K


(Celine) #3

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!


(Trung) #4

#30daytestingchallenge
#day11of 30daytestingchallenge

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:


(Heather) #5

Grabbing some tweets for this:


(Kumar) #6

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.

More source here: https://qakumar.wordpress.com/2018/07/15/day-11-compare-and-contrast-mockingstubbing-and-faking/