Why Mocking external services in Django? - Purpose & Use Cases

The Big Idea

What if you could test your app without waiting for slow or unreliable external services?

The Scenario

Imagine testing your Django app that calls an external payment service every time a user makes a purchase.

You have to wait for the real service to respond, and sometimes it's slow or down.

This makes your tests slow and unreliable.

The Problem

Manually calling real external services during tests is slow and can fail unpredictably.

It also costs money and can cause inconsistent test results if the service changes or is unavailable.

The Solution

Mocking external services lets you replace real calls with fake ones that return controlled responses instantly.

This makes tests fast, reliable, and safe without depending on outside systems.

Before vs After

✗ Before

response = requests.post('https://payment.example.com/pay', data=payment_data)
assert response.status_code == 200

✓ After

from unittest import mock

with mock.patch('requests.post') as mock_post:
    mock_post.return_value.status_code = 200
    response = requests.post('https://payment.example.com/pay', data=payment_data)
    assert response.status_code == 200

What It Enables

It enables you to test your app's behavior quickly and reliably without real external dependencies.

Real Life Example

When testing user signup that sends a confirmation email via an external service, mocking lets you verify the email was "sent" without actually sending it.

Key Takeaways

Manual external calls in tests are slow and unreliable.

Mocking replaces real calls with fast, fake responses.

This makes tests faster, safer, and consistent.

Practice

1. What is the main reason to use mocking for external services in Django tests?

easy

A. To avoid making real network calls during tests

B. To speed up the Django development server

C. To automatically generate API documentation

D. To deploy the Django app faster

Solution

1. Step 1: Understand the purpose of mocking

   Mocking replaces real external calls with fake ones to avoid delays and failures during tests.

2. Step 2: Identify the benefit in testing context

   By not making real network calls, tests run faster and are more reliable.

3. Final Answer:

   To avoid making real network calls during tests -> Option A

4. Quick Check:

   Mocking avoids real calls = A [OK]

Hint: Mock external calls to keep tests fast and reliable [OK]

Common Mistakes:

• Thinking mocking speeds up the server
• Confusing mocking with deployment
• Assuming mocking generates docs

2. Which of the following is the correct way to patch an external service call in a Django test using unittest.mock?

easy

A. @patch('services.external_api_call.myapp')

B. @patch('external_api_call.myapp.services')

C. @patch('myapp.external_api_call.services')

D. @patch('myapp.services.external_api_call')

Solution

1. Step 1: Understand patch target format

   The patch decorator requires the full import path to the function or method to mock.

2. Step 2: Match the correct import path

   @patch('myapp.services.external_api_call') correctly specifies the module and function as 'myapp.services.external_api_call'.

3. Final Answer:

   @patch('myapp.services.external_api_call') -> Option D

4. Quick Check:

   Correct patch path = D [OK]

Hint: Patch using full import path of the function to mock [OK]

Common Mistakes:

• Reversing module and function order
• Using incomplete import paths
• Patching the wrong module

3. Given this test code snippet, what will be printed?

from unittest.mock import patch

def get_data():
    return external_service_call()

@patch('myapp.services.external_service_call')
def test_get_data(mock_call):
    mock_call.return_value = {'status': 'ok'}
    result = get_data()
    print(result)

medium

A. Error: external_service_call not defined

B. None

C. external_service_call

D. {'status': 'ok'}

Solution

1. Step 1: Understand patch effect on external_service_call

   The patch replaces external_service_call with a mock that returns {'status': 'ok'} only inside the decorated function test_get_data.

2. Step 2: Analyze get_data call outside patch scope

   get_data() calls external_service_call(), but external_service_call is not defined globally, leading to a NameError.

3. Final Answer:

   Error: external_service_call not defined -> Option A

4. Quick Check:

   external_service_call undefined outside patch = D [OK]

Hint: Patch only affects references inside the decorated function [OK]

Common Mistakes:

• Assuming patch affects global scope
• Expecting mock return_value outside patch
• Ignoring NameError due to missing definition

4. What is wrong with this test code that tries to mock an external API call?

from unittest.mock import patch

def test_api_call():
    with patch('myapp.services.external_api_call') as mock_call:
        mock_call.return_value = {'success': True}
    result = external_api_call()
    print(result)

medium

A. external_api_call cannot be patched with patch()

B. The patch context ends before calling external_api_call

C. mock_call.return_value should be set after calling external_api_call

D. Missing import for external_api_call

Solution

1. Step 1: Check patch context usage

   The patch is applied only inside the with block, but external_api_call is called after it ends.

2. Step 2: Understand effect on mocking

   Since external_api_call is called outside the patch block, it is not mocked and runs the real function.

3. Final Answer:

   The patch context ends before calling external_api_call -> Option B

4. Quick Check:

   Call must be inside patch block = C [OK]

Hint: Call mocked function inside patch block or decorator [OK]

Common Mistakes:

• Calling function outside patch context
• Setting return_value too late
• Assuming patch works globally without context

5. You want to test a Django view that calls an external payment API. Which approach correctly mocks the external call and verifies the view handles a failure response gracefully?

from unittest.mock import patch
from django.test import Client

@patch('payments.api.call_payment')
def test_payment_failure(mock_call):
    mock_call.return_value = {'status': 'error', 'code': 500}
    client = Client()
    response = client.post('/pay/')
    print(response.status_code)

What should you add to the test to check the view's behavior?

hard

A. Assert response.status_code is 500 to confirm failure handling

B. Remove patch decorator to test real API call

C. Assert mock_call was called once and response.status_code is 200

D. Set mock_call.return_value to None to simulate failure

Solution

1. Step 1: Understand mocking external payment API

   The patch replaces call_payment with a mock returning an error response.

2. Step 2: Verify view handles error but returns HTTP 200

   The view should catch the error and respond with HTTP 200 (page loads with error message), not propagate 500.

3. Step 3: Check mock call was made

   Asserting mock_call was called confirms the external API was invoked in the view.

4. Final Answer:

   Assert mock_call was called once and response.status_code is 200 -> Option C

5. Quick Check:

   Mock call checked + 200 response = B [OK]

Hint: Check mock call and expect view to handle errors with 200 [OK]

Common Mistakes:

• Expecting 500 status from view on API error
• Not asserting mock call was made
• Removing patch and making real calls