Today’s challenge is about explaining mocks, stubs and fakes.
I don’t know if I can pull it off.
The problem is, different teams will use these words in different ways. I don’t think it makes a lot of sense to argue about what exactly each of them means and how they are distinct from each other, but there is some value in at least understanding the general idea that these terms are meant to communicate.
In the broadest terms, when we talk about these things we are talking about something that is a substitute for a piece of production code. For example, we might have a database that stores some values. When running tests though, it might expensive to go retrieve those values many times, so instead we might make a local text file that has a few of the values we care about hard coded into it and just use that instead of the ‘real’ databases.
No matter what term we are talking about – mocking, stubbing, faking, etc. – what we are doing is using something that is not the production code to simplify in some way what we are doing for our tests. This helps us isolate things to just the specific part of the code we are interested in and can be used in some really powerful ways.
I wouldn’t worry too much about understanding in an absolute sense what these various terms means. What matters in figuring out what they mean in your context. How do the members of your team use these terms? What do they mean by them? How do the tools that you use talk about these things and what do they mean by it? Understanding how the terms are used in the contexts in which you work will help you better communicate with those that you work with.
The idea of mocking, stubbing or faking something is a very powerful testing concept and well worth taking the time to learn how to do, but don’t get too caught up in the specifics of the terminology.
Photo by Jelleke Vanooteghem on Unsplash