Mocking __init__ methods in Python

Patching a class's __init__ method is a common and powerful technique for unit testing code that relies on objects whose initialization performs unwanted side effects. These side effects can include making API calls, connecting to a database, or performing other time-consuming or stateful operations [1]. By mocking __init__, you can prevent these actions and verify that the class was instantiated correctly.

The Problem: Side Effects in __init__

Consider a Service class that makes a database connection as soon as it's initialized.

data_service.py

import database_client

class DataService:
    def __init__(self, db_path):
        # A side effect happens here: a connection is made to the database
        self.db_client = database_client.connect(db_path)

    def get_user_count(self):
        # This method would use the client to query data
        return self.db_client.query("SELECT COUNT(*) FROM users")

If you were to test a function that uses DataService, your test would fail if a database isn't running or would be slow due to the real connection being made.

---

The Solution: Patching __init__

To test a function that uses DataService without making a real connection, you can mock the __init__ method of the DataService class itself. The goal is to replace __init__ with a mock that does nothing, allowing you to create a DataService instance instantly and without side effects.

The patch decorator is the key here, but the target needs to be precise. You must patch the __init__ method of the class where it is defined, which can be tricky. A more common and often simpler approach is to patch the entire class and then configure the behavior of the __init__ method on the mock [2].

Example: Mocking a Class and its __init__

Let's test a Reporter function that initializes and uses the DataService.

reporter.py

from data_service import DataService

def generate_user_report(db_path):
    data_service = DataService(db_path)
    count = data_service.get_user_count()
    return f"Total users: {count}"

To test generate_user_report without touching the database, we patch the DataService class itself.

test_reporter.py

import unittest
from unittest.mock import patch, MagicMock
from reporter import generate_user_report

class TestReporter(unittest.TestCase):
    
    # We patch the DataService class where it's imported
    @patch('reporter.DataService')
    def test_generate_user_report_success(self, MockDataService):
        # The mock object passed to the test function is the mock class itself
        
        # Configure the mock instance that will be returned when DataService() is called
        mock_instance = MockDataService.return_value
        
        # Configure the behavior of the mocked method on the instance
        mock_instance.get_user_count.return_value = 100
        
        # Now, when our function calls `DataService()`, it gets our mock
        report = generate_user_report('my_db.sqlite')
        
        # Assertions on the mock class
        MockDataService.assert_called_once_with('my_db.sqlite')
        
        # Assertions on the mock instance's method
        mock_instance.get_user_count.assert_called_once()
        
        self.assertEqual(report, "Total users: 100")

In this scenario, __init__ is implicitly mocked. When you patch the DataService class, the MockDataService object that replaces it is a callable that, when called, returns a new mock object. This new mock object is the stand-in for our DataService instance. We can then configure its methods, like get_user_count, without ever executing the real __init__ method [3].

---

Alternative: Mocking database_client.connect

In some cases, it might be cleaner to mock the specific side effect rather than the entire class. If __init__'s only side effect is the database_client.connect call, you can patch just that.

test_reporter_alt.py

import unittest
from unittest.mock import patch, MagicMock
from reporter import generate_user_report

class TestReporterAlternative(unittest.TestCase):
    
    # Patch the `connect` function where it's used
    @patch('data_service.database_client.connect')
    def test_generate_user_report_connect_mock(self, mock_connect):
        mock_db_client = MagicMock()
        mock_db_client.query.return_value = 100
        mock_connect.return_value = mock_db_client
        
        report = generate_user_report('my_db.sqlite')
        
        mock_connect.assert_called_once_with('my_db.sqlite')
        mock_db_client.query.assert_called_once()
        
        self.assertEqual(report, "Total users: 100")

This approach is a good alternative when the side effect is well-defined and isolated. The choice between patching the class and patching the specific side effect depends on which method results in more readable and maintainable tests. Generally, mocking at the highest possible level is a good practice, as it reduces the number of mocks you need to manage.

---

Key Takeaways

• Don't patch __init__ directly: Instead of writing @patch('my_module.MyClass.__init__'), patch the entire class with @patch('my_module.MyClass') and configure the mock's return_value [2].
• Control the mock instance: When you patch a class, the mock object returned by the decorator (MockMyClass) is a callable. Its return_value is the mock instance that your code will receive.
• Verify instantiation: Use assertions like MockMyClass.assert_called_once_with(...) to ensure your code instantiated the class with the correct arguments.

This concludes our deep dive into mocking methods and classes. By mastering these techniques, you can write truly isolated, fast, and reliable unit tests.

Sources

1. Mocking in Python: A Practical Guide
2. Python Unit Testing with Mock: Patching Classes
3. Understanding Patch Decorators in Python's unittest
4. Python Mocking: The Ultimate Guide
5. The mock object library