Automated testing during software development involves many different techniques, one that shouldn’t be used is mocking. Mocks are a distraction at best and provide false confidence at worst.
What is Mocking?
It is common for software developers to use mocks to simulate behaviour of code for network calls to other services or for database access. This enables unit tests to be run that are both:
- Fast because they don’t need to rely on additional services.
- Stable because they avoid availability issues.
This means that mocks are generally used for code with side effects, which is code that relies on or modifies something outside its parameters. This lets us classify functions as:
- Pure: A function without any side effects.
- Impure: A function that contains one or more side effects.
The Problems with Mocks
Mocks aren’t equivalent to the integrations they replace.
If you mock a database client then you haven’t tested the integration with the real client. This means that your code may work with the mock but you will still need to do integration testing to make sure it works without mocks.
Feature Parity Is Not Feasible.
If you make a quick mock then it won’t return useful data. The more time you spend improving the mock the more useful the data will be. However it can never be a true representation.
Mocks that aren’t used are a waste of time and effort.
If you mock out a database client and don’t use it then there is no point mocking it. This can occur if some code requires valid configuration to initialise but doesn’t use it.
How Do We Replace Mocks?
Mocks are used to provide speed and stability but we can manage this in other ways.
Refactor your code! We can replace the need for mocks by separating the pure from the impure functions. Pure functions can be unit tested without mocks and impure functions should only be integration tested.
Improve Your Automation! By automating software packaging, deployment, and testing we can focus on integration testing faster instead of relying on unit tests. This also enables continuous delivery and reduces the impact of “it works on my machine” which are beneficial in modern software development.
Summary
Mocking is a short term solution and a long term problem. If you want to deliver software faster then you should spend less time on mocks and more time on refactoring and automation.
If you would like to see more content like this follow me on medium.
Let me know your thoughts on Twitter @BenTorvo or by Email ben@torvo.com.au