In the post Mock? What, When, How? by Lovis Möller, he discusses mocking and when to use it. Mocking is a strategy used in test-driven development where a mock object is created to test the interactions and dependencies this class has with other classes. Lovis talks about looking at his own and other people’s code and determines some situations in which he would use or would not use mocking, and why he would or would not use it.
Lovis first point is that you should only mock types that are internal to your program, and avoid mocking external types. External types may have dependencies of their own that you don’t know about, and could change in a later version of the code. Avoiding mocking makes your code more adaptable for future versions. The next thing Lovis recommends is that you do not mock values. If you mock values, you aren’t actually testing any useful part of the code. Lovin states:
“Mocking is a technique that is used to make the relationships and interactions between objects visible.”
The last big example Lovis gives is to not to mock concrete classes. The example and associated code he gives makes it pretty clear, as the result depends on a method that has not been covered by the mocked methods within the code. It is easy to see how this could get out of hand if you had to covered each method of a mocked class for your mock testing.
I had a lot of trouble understanding mocking and when you would want to use and and why before reading this post. Although it is still a difficult concept to understand why we are making these mock objects, seeing circumstances in which you would or wouldn’t want to use mocking, and alternatives to mocking make it a little easier to see how it is testing a program and why it is a useful concept. The quote I selected above made this even more apparent to me. Mocking isn’t testing the implementation or your program so much as the relationships between objects and their methods and how they interact.