Dear community, unit tests are an important part of my work as a developer. They help me to implement the topic of “testability” from the CleanABAP triad “readable, testable, maintainable”. I like (among many other advantages) being able to execute tests in the development system – without transporting them to the quality assurance system. This saves time, creates experiences and security, and interrupts me less during programming.
An important prerequisite for unit tests is that the dependencies of the object to be tested are met. For example, if you are testing a class that determines statistics on a protocol and is given this protocol as a separate object, we need such a protocol object as a test double for our unit tests.
Variety of terms
Different specialist literature and websites use different terms to categorize these test doubles. These include dummy, fake, stub, mock, spy, shim and more. It’s typical for us humans: we have to make a science out of everything straight away. But that presupposes that everyone has the same definition of the terms within this science. That doesn’t seem to be the case here, at least to me. And there’s no need to make everything complicated.
My solution approach
After a long back and forth, I came up with a simpler categorization for myself. Here are my three points:
- All test doubles are basically “mock objects”.
- If these mock objects are created by a framework (mocking framework), they are “mocks”.
- If I create these mock objects myself as a class by programming, they are “fakes”.
These three lines are easy to explain.
Point 1 might almost be enough. In my experience, the finer details don’t matter to most developers anyway, because the result is what counts: A mock object with a certain behavior is needed.
The question of how you get it is, at least for me, more important (point 2+3). Either a framework creates the required mock object or manual programming is required.
Have fun and stay healthy
Michael