Why Create Mock Objects?

Question

During a recent interview I was asked why one would want to create mock objects. My answer went something like, "Take a database--if you're writing test code, you may not want that test hooked up live to the production database where actual operations will be performed."

Judging by response, my answer clearly was not what the interviewer was looking for. What's a better answer?

Answer 1

I'd summarize like this:

• Isolation - You can test only a method, independently on what it calls. Your test becomes a real unit test (most important IMHO)
• Decrease test development time - it is usually faster to use a mock then to create a whole class just for help you test
• It lets you test even when you don't have implemented all dependencies - You don't even need to create, for instance, your repository class, and you'll be able to test a class that would use this repository
• Keeps you away from external resources - helps in the sense you don't need to access databases, or to call web services, or to read files, or to send emails, or to charge a credit card, and so on...

In an interview, I'd recommend including that mocking is even better when developers use dependency injection, once it allows you to have more control, and build tests more easily.

Answer 2

When unit testing, each test is designed to test a single object. However most objects in a system will have other objects that they interact with. Mock Objects are dummy implementations of these other objects, used to isolate the object under test.

The benefit of this is that any unit tests that fail generally isolate the problem to the object under test. In some cases the problem will be with the mock object, but those problems should be simpler to identify and fix.

It might be an idea to write some simple unit tests for the mock objects as well.

They are commonly used to create a mock data access layer so that unit tests can be run in isolation from the data store.

Other uses might be to mock the user interface when testing the controller object in the MVC pattern. This allows better automated testing of UI components that can somewhat simulate user interaction.

An example:

public interface IPersonDAO {     Person FindById(int id);     int Count(); }  public class MockPersonDAO : IPersonDAO {     // public so the set of people can be loaded by the unit test     public Dictionary<int, Person> _DataStore;      public MockPersonDAO()     {         _DataStore = new Dictionary<int, Person>();     }      public Person FindById(int id)     {         return _DataStore[id];     }      public int Count()     {         return _DataStore.Count;     } }