Testing

Testing code that relies on external services, like a database, can be difficult since the behaviors of these services can change. 

A mock object can control the behavior of a real object in a testing environment by simulating responses from external services.

The code above uses a mock object to test the get_data function’s behavior when calling an API that may either succeed or fail.

Unit tests require static input, but time is dynamic and constantly changing. With FreezeGun, you can freeze time to a specific point, ensuring accurate verification of the tested features.

Including examples in a docstring is helpful. However, examples can become obsolete as the function evolves.

To ensure that the examples remain accurate, use doctest.

To test the same function with multiple test cases, you can do either of the following:

Separate test functions:

This approach involves creating individual test functions for each test case.

def test_add_positive():
assert add(2, 3) == 5

def test_add_negative():
assert add(-2, -3) == -5

def test_add_mixed():
assert add(-2, 3) == 1

def test_add_zero():
assert add(0, 5) == 4

Output:

pytest_parametrize_example.py …F [100%]

=================================== FAILURES ===================================
________________________________ test_add_zero _________________________________

def test_add_zero():
> assert add(0, 5) == 4
E assert 5 == 4
E + where 5 = add(0, 5)

pytest_parametrize_example.py:14: AssertionError
=========================== short test summary info ============================
FAILED pytest_parametrize_example.py::test_add_zero – assert 5 == 4
========================= 1 failed, 3 passed in 0.05s ==========================

Pros:

Each test case is clearly isolated and easy to understand at a glance.

Cons:

Code duplication – the test structure is repeated for each case.

Adding new test cases requires writing a new function each time.

Changes to test structure only need to be made in multiple places.

Use pytest parameterize

This approach uses pytest’s parametrize decorator to run the same test function with different inputs.

import pytest

def add(num1, num2):
return num1 + num2

@pytest.mark.parametrize(
"a, b, expected",
[(2, 3, 5), (-2, -3, -5), (-2, 3, 1), (0, 5, 4)],
ids=["positive numbers", "negative numbers", "mixed signs", "zero and positive"],
)
def test_add(a, b, expected):
assert add(a, b) == expected

Output:

pytest_parametrize_example.py …F [100%]

=================================== FAILURES ===================================
_________________________ test_add[zero and positive] __________________________

a = 0, b = 5, expected = 4

@pytest.mark.parametrize(
"a, b, expected",
[(2, 3, 5), (-2, -3, -5), (-2, 3, 1), (0, 5, 4)],
ids=["positive numbers", "negative numbers", "mixed signs", "zero and positive"],
)
def test_add(a, b, expected):
> assert add(a, b) == expected
E assert 5 == 4
E + where 5 = add(0, 5)

pytest_parametrize_example.py:14: AssertionError
=========================== short test summary info ============================
FAILED pytest_parametrize_example.py::test_add[zero and positive] – assert 5 == 4
========================= 1 failed, 3 passed in 0.06s ==========================

Pros:

Easy to add new test cases by adding to the parameter list.

Changes to test structure only need to be made in one place.

Cons:

The purpose of each test case might be less immediately clear, especially for complex tests.

Choosing between these methods depends on your project’s needs. Use individual functions when clarity is crucial. Use parametrize when dealing with numerous similar cases.
Favorite

Traditional mocking with unittest.mock often requires repetitive setup and teardown code, which can make test code harder to read and maintain.

pytest-mock addresses this issue by leveraging pytest’s fixture system, simplifying the mocking process and reducing boilerplate code.

Consider the following example that demonstrates the difference between unittest.mock and pytest-mock.

Using unittest.mock:

%%writefile test_rm_file.py
from unittest.mock import patch
import os

def rm_file(filename):
os.remove(filename)

def test_with_unittest_mock():
with patch("os.remove") as mock_remove:
rm_file("file")
mock_remove.assert_called_once_with("file")

Using pytest-mock:

%%writefile test_rm_file.py
import os

def rm_file(filename):
os.remove(filename)

def test_unix_fs(mocker):
mocker.patch("os.remove")
rm_file("file")
os.remove.assert_called_once_with("file")

Key differences:

Setup: pytest-mock uses the mocker fixture, automatically provided by pytest, eliminating the need to import patching utilities.

Patching: With pytest-mock, you simply call mocker.patch('os.remove'), whereas unittest.mock requires a context manager or decorator.

Cleanup: pytest-mock automatically undoes mocking after the test, while unittest.mock relies on the context manager for cleanup.

Accessing mocks: pytest-mock allows direct access to the patched function (e.g., os.remove.assert_called_once_with()), while unittest.mock requires accessing the mock through a variable (e.g., mock_remove.assert_called_once_with()).

Link to pytest-mock.
Favorite

Testing code that relies on external services, like a database, can be difficult since the behaviors of these services can change.

A mock object can control the behavior of a real object in a testing environment by simulating responses from external services.

Here are two common use cases with examples:

Mocking Time-Dependent Functions

When testing functions that depend on the current time or date, you can mock the time to ensure consistent results.

Example: Testing a function that returns data for the last week

from datetime import datetime, timedelta

def get_data_for_last_week():
end_date = datetime.now().date()
start_date = end_date – timedelta(days=7)
return {
"start_date": start_date.strftime("%Y-%m-%d"),
"end_date": end_date.strftime("%Y-%m-%d"),
}

Now, let’s create a test for this function using mock:

from datetime import datetime
from unittest.mock import patch
from main import get_data_for_last_week

@patch("main.datetime")
def test_get_data_for_last_week(mock_datetime):
# Set a fixed date for the test
mock_datetime.now.return_value = datetime(2024, 8, 5)

# Call the function
result = get_data_for_last_week()

# Assert the results
assert result["start_date"] == "2024-07-29"
assert result["end_date"] == "2024-08-05"

# Verify that datetime.now() was called
mock_datetime.now.assert_called_once()

This test mocks the datetime.now() method to return a fixed date, allowing for predictable and consistent test results.

Mocking API calls

When testing code that makes external API calls, mocking helps avoid actual network requests during testing.

Example: Testing a function that makes an API call

import requests
from requests.exceptions import ConnectionError

def get_data():
"""Make an API call to Postgres"""
try:
response = requests.get("http://localhost:5432")
return response.json()
except ConnectionError:
return None

from unittest.mock import patch
from requests.exceptions import ConnectionError
from main import get_data

@patch("main.requests.get")
def test_get_data_fails(mock_get):
"""Test the get_data function when the API call fails"""
# Define what happens when the function is called
mock_get.side_effect = ConnectionError
assert get_data() is None

@patch("main.requests.get")
def test_get_data_succeeds(mock_get):
"""Test the get_data function when the API call succeeds"""
# Define the return value of the function
mock_get.return_value.json.return_value = {"data": "test"}
assert get_data() == {"data": "test"}

These tests mock the requests.get() function to simulate both successful and failed API calls, allowing us to test our function’s behavior in different scenarios without making actual network requests.

By using mocks in these ways, we can create more reliable and controlled unit tests for our data projects, ensuring that our code behaves correctly under various conditions.
Favorite