3.5. Tips for Effective Mocking

● Mock only external dependencies, not the system under test.

When writing tests, it's essential to focus on only the components that interact externally with your system, such as databases, APIs, or file systems. This means that when we use mocking, we should replace these external elements with controlled substitutes (mocks) that simulate their behavior without calling the actual dependencies. This allows our tests to run faster and more reliably, as they are not dependent on the availability and performance of outside systems.

Imagine you're a chef testing a new recipe for a dish that usually requires fresh vegetables. Instead of waiting for the delivery of those fresh vegetables and risking delays, you decide to use canned vegetables to mimic their taste and texture but still allows you to evaluate the essence of your dish. Similarly, in mocking, we create substitute components to test our systems without the external dependencies.

● Use context managers or decorators for patching.

Patching is a technique used within mocking to replace real objects with mocks. This can either be done using decorators or with context managers in Python. A decorator is a specific syntax used in Python that helps modify functions or methods easily, while context managers allow for a setup and teardown process that automatically handles resource management. Using either method helps keep the tests clean and makes sure that mocks are only active during the test and are automatically cleaned up afterward.

Think of patching like wearing a raincoat. When it's raining, you put on the raincoat (the patch) to protect yourself (your code), but as soon as you are indoors, you take it off. Similarly, context managers handle putting on and taking off mocks as needed for each test.

● Reset mocks between tests to avoid state leakage.

When you run tests sequentially, one test can potentially affect another if they share state, which is often the case when using mocks. State leakage can lead to unpredictable results in your tests. To avoid this, it's crucial to reset mocks after each test execution to ensure they start in a consistent state and do not carry over any changes or calls from previous tests. This practice upholds the principle of unit testing that each test should be independent of the others.

Imagine you are conducting a series of experiments in a lab. If you don't clean and reset your equipment after each experiment, the results of one experiment might wrongly influence the next. Similarly, resetting mocks ensures that each test runs in a clean state without any leftover data from previous tests.

--