Testing your code is advisable. I generally start with end-to-end integration tests, to ensure whatever I’m writing does whatever it’s supposed to do. However, as you get deeper into the details, more specific unit testing become necessary. Test doubles such as mocks and stubs can also help in testing the desired behaviours happen in corner cases that are harder to reproduce. Sometimes, though, integration and unit tests end up looking a lot like each other, which always makes me feel like they could be de-duplicated.

I recently came across a situation where I wanted to test some caching behaviour, to ensure that a call only happened if necessary. While it would have been easy to write a separate, dedicated unit test with a stub faking the state of the system, and a mock of the method to check whether it got called or not, it was easier to leverage the existing integration test with additional assertions.

In Python, the unittest.mock.MagicMock can easily replace a function or an object’s method for the sake of checking call counts. However, it prevents the original behaviour from happening, which limits the ability of using mocks in integration tests. It is possible to provide a side effect to the mock, so it does something useful. With some additional boilerplate, the original method getting mocked can be added as a side_effect to the mock, so whatever it does still happens.

tl;dr: I ended up writing a small fixture to avoid too much boilerplate.

from collections.abc import Callable
from typing import Any
from unittest.mock import MagicMock

@pytest.fixture
def active_mock() -> Callable:
    def active_mock(obj: object, method: str) -> MagicMock:
        """Mock a method without preventing its side-effect from happening."""
        original = getattr(obj, method)
        mock_method = MagicMock()
        mock_method.side_effect = original
        setattr(obj, method, mock_method)
        return mock_method

    return active_mock