Testing with pytest

Fixtures: shared setup

Many tests need the same starting point: a cart with two items, a temporary database, a logged-in user. A fixture is a function decorated with @pytest.fixture that builds it. Any test that names the fixture as a parameter gets a fresh one:

import pytest
from cart import Cart

@pytest.fixture
def cart():
    c = Cart()
    c.add("TE-101", price=200)
    c.add("CA-132", price=5, qty=2)
    return c

def test_total(cart):
    assert cart.total() == 189.0        # 210 with 10% off for orders of 100 or more

def test_remove(cart):
    cart.remove("CA-132")
    assert cart.total() == 180.0

Each test gets its own new cart, so test_remove can't affect test_total: tests stay independent and can run in any order. A fixture can yield instead of return, and the code after the yield runs as cleanup, like a context manager. Fixtures used by many test files go in a file called conftest.py, which pytest loads automatically, with no import needed.

pytest has built-in fixtures too. Name them as parameters and they appear: tmp_path (a fresh temporary folder for each test), capsys (what the code printed), monkeypatch (temporary changes, see below) and caplog (log records).

Many cases, one test: parametrize

When the same check applies to many inputs, list them instead of copying the test:

from pathlib import Path
import pytest

Path("discount.py").write_text('''
def discount(subtotal):
    return 0.1 if subtotal >= 100 else 0.0
''')
Path("test_discount.py").write_text('''
import pytest
from discount import discount

@pytest.mark.parametrize("subtotal, expected", [
    (0, 0.0),
    (99.99, 0.0),
    (100, 0.1),
    (100.01, 0.1),
    (2500, 0.1),
])
def test_discount(subtotal, expected):
    assert discount(subtotal) == expected
''')
pytest.main(["-q", "-p", "no:cacheprovider", "test_discount.py"])

Each row runs as its own test and is reported separately, so a failure names the exact input. Notice the rows crowd around 100. Bugs live at boundaries: >= written as >, an off-by-one in a range, an empty list. Always test the edge, just below it and just above it.

import pytest
print(0.1 + 0.2 == 0.3, 0.1 + 0.2 == pytest.approx(0.3))

Faking the slow and unpredictable parts

Some code depends on things a test can't control: the clock, random numbers, environment variables, a real API. monkeypatch swaps something out for the length of one test and puts it back afterwards:

def test_uses_key_from_environment(monkeypatch):
    monkeypatch.setenv("SMS_KEY", "test-key")
    assert load_settings()["sms_key"] == "test-key"

def test_report_date(monkeypatch):
    monkeypatch.setattr(report, "today", lambda: date(2025, 6, 30))
    assert report.title() == "Report for June 2025"

For checking how something was called, unittest.mock provides mock objects that record every call made to them:

from unittest.mock import Mock

def notify_if_cheaper(price, target, send):
    if price <= target:
        send(f"Now ${price:.2f}")
        return True
    return False

send = Mock()
assert notify_if_cheaper(356.25, 400, send) is True
send.assert_called_once_with("Now $356.25")
assert notify_if_cheaper(500, 400, send) is False
print("calls recorded:", send.call_count, send.call_args_list)

Passing send in as a parameter, as in the alert-bot project, is what makes it easy to replace. Code that reaches out for its dependencies (calling requests.get deep inside) needs patching; code that receives them can simply be handed a fake. Don't overdo mocks, though: a test that mocks everything checks only that the code calls what you told it to call.

How good are your tests?

A test suite's job is to catch bugs. Passing isn't the goal; a suite with no assertions passes too. Two ways to judge it:

• Coverage measures which lines the tests ran: pytest --cov=cart with the pytest-cov plugin, or coverage run -m pytest then coverage report. A line no test runs is certainly untested. But running a line doesn't mean checking it: 100% coverage with weak asserts can still miss every bug. Use coverage to find gaps, not as a score to hit.
• Plant a bug and see if the tests notice. Change >= to >, delete a validation, return the wrong value. If everything still passes, a test is missing. Tools called mutation testers do this automatically; the exercise below does it by hand, and checks your tests the same way.

Good tests are also fast, independent of each other and of the order they run in, and named for the behavior they check (test_discount_starts_at_exactly_100), so a failure explains itself. When a bug is reported, write a test that reproduces it first, watch it fail, then fix the code: that bug can never quietly return.

from pathlib import Path
import pytest

Path("report.py").write_text('''
import json

def save_report(rows, folder):
    path = folder / "report.json"
    path.write_text(json.dumps(rows))
    print(f"saved {len(rows)} rows to {path.name}")
    return path
''')
Path("test_report.py").write_text('''
import json
import pytest
from report import save_report

@pytest.fixture
def rows():
    return [{"sku": "TE-101", "qty": 2}, {"sku": "PA-108", "qty": 1}]

def test_saves_json(rows, tmp_path):
    path = save_report(rows, tmp_path)
    assert json.loads(path.read_text()) == rows

def test_prints_summary(rows, tmp_path, capsys):
    save_report(rows, tmp_path)
    assert capsys.readouterr().out == "saved 2 rows to report.json\\n"
''')
code = pytest.main(["-q", "-p", "no:cacheprovider", "test_report.py"])
print("exit code:", code)