Mocking external services in Django - Mini Project: Build & Apply

Mocking External Services in Django Tests

📖 Scenario: You are building a Django app that fetches weather data from an external API. To test your app without calling the real API every time, you will mock the external service.

🎯 Goal: Create a Django test that mocks an external weather API call to return fixed data, so tests run fast and reliably without internet.

📋 What You'll Learn

Create a function that calls an external weather API

Set up a test case in Django

Mock the external API call in the test

Verify the mocked data is used in the test

💡 Why This Matters

🌍 Real World

Mocking external services helps you test your Django apps quickly and reliably without depending on real APIs or internet connection.

💼 Career

Many jobs require writing tests that mock external APIs to ensure code quality and avoid flaky tests caused by network issues.

1

Create a function to fetch weather data

Create a function called get_weather(city) in a file named weather.py. This function should use the requests library to get JSON data from https://api.weather.com/v1/{city} and return the JSON response.

Django

# Your code here

Hint

Use requests.get with an f-string URL and return response.json().

2

Set up a Django test case

Create a Django test case class called WeatherTestCase in tests.py. Import TestCase from django.test and the get_weather function from weather. Define a test method test_get_weather inside the class.

Django

import requests

def get_weather(city):
    response = requests.get(f'https://api.weather.com/v1/{city}')
    return response.json()

# Your code here

Hint

Import TestCase and create a class with a test method stub.

3

Mock the external API call in the test

In the test_get_weather method, use unittest.mock.patch to mock requests.get. Make the mock return an object whose json() method returns {'temp': 20, 'condition': 'sunny'}. Call get_weather('London') and save the result in a variable called data.

Django

import requests
from django.test import TestCase
from weather import get_weather
from unittest.mock import patch, Mock

class WeatherTestCase(TestCase):
    def test_get_weather(self):
        # Your code here

Hint

Use patch as a context manager to replace requests.get. Set mock_response.json.return_value to the fixed dictionary.

4

Verify the mocked data is used in the test

Add an assertion in test_get_weather to check that data['temp'] equals 20 and data['condition'] equals 'sunny'.

Django

import requests
from django.test import TestCase
from weather import get_weather
from unittest.mock import patch, Mock

class WeatherTestCase(TestCase):
    def test_get_weather(self):
        with patch('requests.get') as mock_get:
            mock_response = Mock()
            mock_response.json.return_value = {'temp': 20, 'condition': 'sunny'}
            mock_get.return_value = mock_response
            data = get_weather('London')
            # Your code here

Hint

Use self.assertEqual to check the values in data.

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