Mock is an easily abused tool. In perverse cases, it increases technical debt and prevents refactoring. This talk describes the history of mocking, alternatives, anti-patterns, and the connection to clean architecture.
Mocking in Python is tricky. Most widely available materials on Python mocks serve as a basic operator’s manual for the library, but scarcely address the code smells and technical debt that mocks may create.
An important idea that is commonly misunderstood, is that mocks were never originally intended to simply be a tool for decoupling dependencies. Mocking originated as a practice with deep roots in OOP and TDD practice, and has a deep catalog of knowledge related to their use and mis-use.
This session will trace the origins of mocking in XP, OOP, and TDD and relate it to contemporary practice, to show how developers may be mis-lead. It will demonstrate some bad code smells related to mocks, as well as alternative solutions. It is assumed that attendees are already familiar with Python mock, MagicMock, and patch.
The content will also serve as an entry point into some more advanced software architecture concepts (test doubles, dependency injection, hexagonal/onion architectures).
This knowledge should be useful to engineers or teams who have technical debt related to mocking and patching in their unit tests, but cannot explain why.
Code-Review, Web, Data Engineering
Domain Expertise:none
Python Skill Level:basic
Link to talk slides: Abstract as a tweet:Mock Hell: How to escape and avoid it, and improve your design in the process.