The Dangers of Mocking in Software Development
Written on
Understanding the Risks of Mocking
In the realm of automated testing within software development, various techniques are employed. However, one approach that often proves detrimental is mocking. At best, mocks can distract developers, and at worst, they can create a false sense of security.
What Exactly is Mocking?
It is a common practice among software engineers to utilize mocks to imitate the behavior of network calls to external services or database access. This allows unit tests to be executed in a manner that is both:
- Quick, as they do not depend on external services.
- Reliable, since they bypass potential availability concerns.
Mocks are typically employed for functions that have side effects—meaning they either depend on or modify something outside their defined parameters. Consequently, we can categorize functions as follows:
- Pure: Functions devoid of any side effects.
- Impure: Functions that exhibit one or more side effects.
The Pitfalls of Using Mocks
Mocks do not accurately reflect the integrations they substitute. For instance, if you mock a database client, you miss out on testing the actual integration with the real client. Your code might work perfectly with the mock, yet you will still need to conduct integration tests to ensure its functionality without mocks.
- Feature Parity is Unattainable: A hastily created mock will not yield meaningful data. The more effort you invest in refining the mock, the more valuable the data becomes. Nonetheless, it can never truly replicate the original.
- Unused Mocks Waste Resources: If you create a mock for a database client that isn’t utilized, then the effort is futile. This situation can arise when some code requires valid configurations to initialize but fails to use them afterward.
Strategies for Moving Beyond Mocks
While mocks are often used for their speed and stability, other strategies can provide similar benefits.
- Refactor Your Code: By distinguishing between pure and impure functions, you can eliminate the need for mocks. Pure functions can be unit tested independently, while impure functions should be reserved for integration testing.
- Enhance Your Automation: By automating the processes of software packaging, deployment, and testing, the focus can shift to faster integration testing rather than relying heavily on unit tests. This approach supports continuous delivery and mitigates the issues often encapsulated in the phrase “it works on my machine,” which are crucial in modern software development.
Conclusion
Ultimately, relying on mocks is a temporary fix that can lead to long-term complications. For those aiming to accelerate software delivery, it is advisable to devote less time to mocking and more time to refactoring and enhancing automation.
If you’re interested in additional insights like this, consider following me on Medium. I welcome your feedback on Twitter @BenTorvo or via email at [email protected].
In this video titled "CppCon 2017: Peter Sommerlad “Mocking Frameworks considered harmful”," Peter Sommerlad discusses the pitfalls of using mocking frameworks in software development.
The second video, "Mocking Frameworks considered, harmful?! - Peter Sommerlad [ACCU2018]," further explores the negative implications of mocking frameworks in software testing.