Posted inPython

Mastering unittest.mock: Don’t Let ‘Dead’ APIs Break Your Unit Tests

Python tutorial - IT technology blog
Python tutorial - IT technology blog

The 2 AM Phone Call and a Lesson in Unit Testing

I still vividly remember a system shift three years ago. At exactly 2 AM, my Slack screen buzzed continuously as the CI/CD pipeline turned bright red. The whole team scrambled to check, but the logic code was perfectly fine. The cause turned out to be extremely rare: a partner’s API was undergoing scheduled maintenance. Once, a test even failed just because someone accidentally “dropped a table” in the shared database server.

That was when I realized a harsh truth. If your Unit Test still needs the Internet to run, you are actually doing Integration Testing without knowing it. A true Unit Test must completely isolate logic from external factors. To solve this dependency once and for all, unittest.mock is a must-have tool in any Python developer’s toolkit.

Why You Should Stop Using Real Connections During Testing

Let’s look at three common approaches when handling code that calls an API or Database:

  • Real Connection: You set up a test database or call a real API. This is accurate but extremely slow. A test suite could take 15 minutes to run instead of 30 seconds, not to mention the risk of unstable network connections.
  • Manual Fake Objects: You write your own mock classes. This is high maintenance and causes test files to bloat quickly.
  • Using unittest.mock: You replace dependencies with “mock” objects. You can force them to return any result or simulate server errors with just two lines of code.

The biggest advantage of unittest.mock is that it’s built into Python’s standard library (since version 3.3). You don’t need to install external libraries. It’s incredibly flexible, allowing you to “swap” a function, a class, or even an object attribute while the test is running.

How to Mock APIs for Faster Testing

Suppose you have a function that fetches gold prices from an API. If that website goes down, your test breaks. Here’s how we isolate it:

import requests

def get_gold_price(api_url):
    response = requests.get(api_url)
    if response.status_code == 200:
        return response.json()["price"]
    return None

Instead of calling the real requests.get, we use the @patch decorator to control the return value:

import unittest
from unittest.mock import patch

class TestGoldAPI(unittest.TestCase):
    @patch('requests.get')
    def test_get_gold_price_success(self, mock_get):
        # Simulate server response
        mock_get.return_value.status_code = 200
        mock_get.return_value.json.return_value = {"price": 2000}

        result = get_gold_price("http://fake-api.com")
        
        self.assertEqual(result, 2000)
        # Verify the function was called with the correct parameters
        mock_get.assert_called_once_with("http://fake-api.com")

Mocking Databases: Saving Hours of Waiting

Interacting with a database in Unit Tests is often a performance nightmare. Instead of waiting several hundred milliseconds for the DB to execute a SQL statement, Mocking helps you get results instantly in 1-2 milliseconds. Here is how to mock a Database session with SQLAlchemy:

from unittest.mock import MagicMock

def test_delete_user_exists():
    # Create a mock session
    mock_session = MagicMock()
    
    # Simulate the query.filter_by.first chain
    mock_user = MagicMock()
    mock_session.query.return_value.filter_by.return_value.first.return_value = mock_user

    result = delete_user(mock_session, 123)

    assert result is True
    mock_session.delete.assert_called_once_with(mock_user)
    mock_session.commit.assert_called_once()

In practice, when processing input data before saving to the DB, I frequently run into Regex errors. To save debugging time in test code, I often use a Regex tester to check patterns before putting them into Python. This significantly reduces the number of times I have to rerun Unit Tests due to a simple backslash error.

Handling Error Scenarios with side_effect

Code doesn’t always run smoothly. A high-quality test suite needs to check how the application behaves if an API times out or the database connection is lost. The side_effect attribute allows you to raise an Exception to test error-handling logic.

@patch('requests.get')
def test_get_gold_price_timeout(self, mock_get):
    # Force the requests.get function to raise a Timeout error
    mock_get.side_effect = requests.exceptions.Timeout

    with self.assertRaises(requests.exceptions.Timeout):
        get_gold_price("http://fake-api.com")

3 Golden Rules for Using Mocks

After years of working with large systems, I’ve drawn three important lessons to prevent Mocking from ruining your test logic:

  1. Mock in the right place: Patch where the object is used, not where it is defined. If app.py imports requests, you need to patch 'app.requests.get'.
  2. Don’t overdo it: If you have to mock more than 5 objects to test a single function, it’s a sign of high coupling. Consider refactoring your logic.
  3. Prioritize MagicMock: This is an upgraded version of Mock that natively supports methods like __iter__ or __len__, making it easier to simulate lists or complex objects.

Mastering Mocking techniques doesn’t just keep your CI/CD green. It gives you the confidence to write code even when a partner’s API isn’t ready yet. Happy coding, and may you never worry about external system failures again!

Share:
Tags: