Compare and contrast mocking, stubbing, and faking.

Yet Another Challenge! Ministry of Testing got us 30 days Testing Challenge.

This time topic is on API Testing.

It has been long time I have worked on API Testing, after learning from API Testing Dojo (year 2015).

14th Challenge: Compare and contrast mocking, stubbing, and faking.

It is one of the challenging topic to understand related to Unit Testing.
  • Test Doubles (Mocks, Stubs, Fakes etc.), are an essential tool when writing unit tests. 
  • A test double is an object that can stand in for a real object in a test, similar to how a stunt double stands in for an actor in a movie for dangerous scenes. 
  • The most common types of test doubles are stubs, mocks, and fakes.
  • Their purpose is to be substituted for dependencies of the class or classes under test.
  • Example: E-mail services are a canonical example - we don't want to send out real e-mails every time we run our tests!
  • Example: we probably don't want to connect to a real database somewhere in our unit tests, as that would make them dependent on that database's state. There are solutions that let you control them from your unit tests - in-memory databases like H2
  •  All Test Doubles can be created using very popular, library: Mockito.
The various types of Test Doubles
  • stub is an artificial object, which has no logic, and only returns what you tell it to return. 
  • Stubs can be used when you need an object to return specific values in order to get your code under test into a certain state. 
  • While it's usually easy to write stubs by hand, using a mocking framework is often a convenient way to reduce boilerplate.
  • Example: To always return the same value, or to throw an exception when called with a particular argument.

  • Mock is an object which records the methods called on it, and allows later verification that the recorded calls match some criteria, such as: the order of calls, their number, the values of parameters, and the absence of any unexpected calls. Test should fail if it's not called that way. 
  • This way of asserting is called behavior verification, which means checking the correctness of a class through analyzing its interactions - in contrast to state verification, which uses the object's state to achieve that.
  • Mocks are used to test interactions between objects, and are useful in cases where there are no other visible state changes or return results that you can verify. 
  • Example: If your code reads from disk and you want to ensure that it doesn't do more than one disk read, you can use a mock to verify that the method that does the read is only called once.

  • A Fake doesn’t use a mocking framework: it’s a lightweight implementation of an API that behaves like the real implementation, but isn't suitable for production (e.g. an in-memory database). 
  • Fakes can be used when you can't use a real implementation in your test.
  • Example: If the real implementation is too slow or it talks over the network. 
  • You shouldn't need to write your own fakes often since fakes should usually be created and maintained by the person or team that owns the real implementation.

  • Stubs: Fake responses to method calls
  • Mocks: Expectations about method calls, verifying them, and faking returning a value
  • Fake: Objects with a working implementation that is useful for tests


This entry was posted in . Bookmark the permalink.

Leave a Reply