Bird
Raised Fist0
PyTesttesting~15 mins

Testing with external services in PyTest - Build an Automation Script

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Verify user data retrieval from external API
Preconditions (2)
Step 1: Send a GET request to https://api.example.com/users/123
Step 2: Receive the JSON response containing user details
Step 3: Verify the response status code is 200
Step 4: Verify the response JSON contains 'id' equal to 123
Step 5: Verify the response JSON contains 'name' and 'email' fields
✅ Expected Result: The API returns status 200 and JSON with correct user id, name, and email fields
Automation Requirements - pytest
Assertions Needed:
Response status code is 200
Response JSON 'id' equals 123
Response JSON contains 'name' key
Response JSON contains 'email' key
Best Practices:
Use requests library to call external API
Use pytest fixtures for setup if needed
Handle possible connection errors gracefully
Avoid hardcoding URLs by using constants
Keep tests independent and repeatable
Automated Solution
PyTest
import requests
import pytest

API_URL = "https://api.example.com/users/123"

@pytest.fixture

def get_user_data():
    try:
        response = requests.get(API_URL, timeout=5)
        response.raise_for_status()
        return response
    except requests.RequestException as e:
        pytest.skip(f"Skipping test due to connection error: {e}")


def test_user_data_retrieval(get_user_data):
    response = get_user_data
    assert response.status_code == 200, f"Expected status 200 but got {response.status_code}"
    data = response.json()
    assert data.get('id') == 123, f"Expected user id 123 but got {data.get('id')}"
    assert 'name' in data, "Response JSON missing 'name' field"
    assert 'email' in data, "Response JSON missing 'email' field"

The code uses requests to call the external API URL defined as a constant API_URL. A pytest fixture get_user_data handles the GET request and skips the test if the API is unreachable or returns an error.

The test function test_user_data_retrieval uses this fixture to get the response, then asserts the status code is 200. It parses the JSON and checks the id is 123 and that name and email keys exist. This keeps the test clear, independent, and handles external service issues gracefully.

Common Mistakes - 4 Pitfalls
Hardcoding the API URL inside the test function
Not handling connection errors or timeouts
Not checking the response status code before parsing JSON
Using print statements instead of assertions
Bonus Challenge

Now add data-driven testing with 3 different user IDs: 123, 456, and 789

Show Hint

Practice

(1/5)
1. What is the main reason to use mocking when testing with external services in pytest?
easy
A. To avoid calling the real external service and make tests faster
B. To increase the number of real API calls during testing
C. To make tests dependent on internet speed
D. To test the external service itself

Solution

  1. Step 1: Understand the role of mocking in tests

    Mocking replaces real external calls with fake ones to avoid delays and failures.
  2. Step 2: Identify the benefit of mocking external services

    Mocking makes tests faster and more reliable by not depending on real services.
  3. Final Answer:

    To avoid calling the real external service and make tests faster -> Option A
  4. Quick Check:

    Mocking speeds up tests by faking external calls [OK]
Hint: Mock external calls to speed tests and avoid failures [OK]
Common Mistakes:
  • Thinking mocking increases real API calls
  • Believing tests should depend on internet speed
  • Confusing testing external service with testing your code
2. Which of the following is the correct way to mock a function get_data from module external_api using pytest's patch decorator?
easy
A. @patch('external_api.get_data')
B. @patch('get_data.external_api')
C. @patch('external_api->get_data')
D. @patch('external_api.getData')

Solution

  1. Step 1: Recall correct patch syntax

    The patch decorator requires the full import path as a string: 'module.function'.
  2. Step 2: Match the correct option

    @patch('external_api.get_data') uses 'external_api.get_data' which is the correct format and case-sensitive.
  3. Final Answer:

    @patch('external_api.get_data') -> Option A
  4. Quick Check:

    patch('module.function') syntax is correct [OK]
Hint: Use 'module.function' string in patch decorator [OK]
Common Mistakes:
  • Swapping module and function order
  • Using wrong separators like '->'
  • Incorrect function name casing
3. Given the following pytest test code, what will be the output when running the test?
from unittest.mock import patch
import requests

def fetch_status():
    response = requests.get('https://api.example.com/data')
    return response.status_code

@patch('requests.get')
def test_fetch_status(mock_get):
    mock_get.return_value.status_code = 200
    assert fetch_status() == 200
    print('Test passed')
medium
A. TypeError
B. AssertionError
C. Test passed
D. No output

Solution

  1. Step 1: Understand mocking effect on requests.get

    The patch replaces requests.get with a mock that returns an object with status_code 200.
  2. Step 2: Check assertion and print statement

    fetch_status() returns 200, matching the assertion, so 'Test passed' is printed.
  3. Final Answer:

    Test passed -> Option C
  4. Quick Check:

    Mocked return_value.status_code = 200 makes test pass [OK]
Hint: Mock return_value to control function output [OK]
Common Mistakes:
  • Forgetting to set return_value.status_code
  • Expecting real HTTP call instead of mock
  • Missing print output due to assertion failure
4. Identify the error in the following pytest test that mocks an external service call:
from unittest.mock import patch
import myservice

@patch('myservice.call_api')
def test_api(mock_call):
    mock_call.return_value = {'status': 'ok'}
    result = myservice.call_api()
    assert result.status == 'ok'
medium
A. The patch decorator is missing parentheses
B. The assertion should use result['status'] instead of result.status
C. mock_call.return_value should be a string, not a dict
D. The test function is missing a return statement

Solution

  1. Step 1: Analyze the mocked return value type

    The mock returns a dictionary {'status': 'ok'}, so result is a dict.
  2. Step 2: Check the assertion syntax

    Accessing dict keys requires bracket notation, not dot notation; result.status causes AttributeError.
  3. Final Answer:

    The assertion should use result['status'] instead of result.status -> Option B
  4. Quick Check:

    Dict keys need brackets, not dot notation [OK]
Hint: Use brackets for dict keys in assertions [OK]
Common Mistakes:
  • Using dot notation on dicts
  • Forgetting parentheses in patch decorator (not here)
  • Expecting return_value must be string always
5. You want to test a function process_data() that calls an external API fetch_data(). The API sometimes returns null. How should you mock fetch_data in pytest to test process_data handles null correctly?
hard
A. Do not mock fetch_data; test process_data only with real data
B. Call the real fetch_data to see if it returns null
C. Mock fetch_data to always raise an exception
D. Use patch to make fetch_data return null and assert process_data handles it

Solution

  1. Step 1: Understand the need to test null handling

    Since fetch_data can return null, tests must simulate this to check process_data behavior.
  2. Step 2: Use patch to mock fetch_data returning null

    Mocking fetch_data to return null allows controlled testing of process_data's handling of that case.
  3. Final Answer:

    Use patch to make fetch_data return null and assert process_data handles it -> Option D
  4. Quick Check:

    Mock null return to test edge case handling [OK]
Hint: Mock edge cases like null to test error handling [OK]
Common Mistakes:
  • Calling real external API in tests
  • Mocking only success cases, ignoring null
  • Ignoring exceptions instead of testing them