Why would I write a fake class and unit test it?

Question

I understand the need to test a class that has logic (for instance, one that can calculate discounts), where you can test the actual class.

But I just started writing unit tests for a project that will act as a repository (get objects from a database). I find myself writing a 'fake' repository that implements an ISomethingRepository interface. It uses a Dictionary<Guid, Something> for storage internally. It implements the Add(Something) and GetById(Guid) methods of the interface.

Why am I writing this? Nothing I'm writing will actually be used by the software when it's deployed, right? I don't really see the value of this exercise.

I also got the advice to use a mock object that I can setup in advance to meet certain expectations. That seems even more pointless to me: of course the test will succeed, I have mocked/faked it to succeed! And I'm still not sure the actual software will perform as it should when connecting to the database...

confused...

Can someone point me in the right direction to help me understand this?

Thank you!

Answer 1

You are not testing your mock object but some other class that is interacting with it. So you could for example test that a controller forwards a save method call to your fake repository. There is something wrong if you are "testing your fake objects"

Answer 2

Don't test the mock class. Do test the production class using the mock class.

The whole point of the test support class is to have something that you can predict its behavior. If you need to test the test support class in order to predict its behavior, there is a problem.

In the fake database article you linked in a comment, the author needs to unit test his fake database because it is his product (at least in the context of the article).

Edit: updated terms to be more consistent.

• Mock - created by mocking framework
• Fake - created manually, might actually function some.
• Test Support - Mocks, Fakes, Stubs, and all the rest. Not production.