Python Unit Testing and pytest

A unit test checks one observable behaviour for a controlled input: given 13 pastries and trays of 6, the function returns 3. Write the expected result down before writing the assertion, from the specification rather than by running the code and copying its output, or you'll enshrine whatever bug the code has.

Good tests follow a simple structure, often called Arrange, Act, Assert:

def test_partly_filled_tray_counts_as_a_whole_tray():
    items, capacity = 13, 6                  # arrange
    result = trays_needed(items, capacity)   # act
    assert result == 3                       # assert

Test the public behaviour, not private details. A test that checks which helper function was called, or the exact internal data structure, fails whenever you refactor, even when the results are still correct. Name tests after the behaviour they protect, so a failure report reads like a broken requirement.

pytest finds tests by convention:

• files named test_*.py or *_test.py,
• functions named test_* at module level,
• methods named test_* inside classes named Test* (without an __init__).

bakery/
    trays.py
tests/
    test_trays.py
pyproject.toml

Run pytest from the project root, pytest tests/test_trays.py for one file, pytest -k capacity for tests whose names match, and pytest -x to stop at the first failure. pytest -v lists every test by name.

A green run can be misleading if nothing was collected. A file named trays_test_cases.py or a function called check_capacity is silently ignored, and pytest reports no tests ran. Check the summary line for the number collected. Settings such as testpaths and pythonpath can be recorded under [tool.pytest.ini_options] in pyproject.toml, so everyone runs the same configuration.

Most bugs live at boundaries: zero, one, exactly full, one over, the largest allowed value. parametrize runs one test function with many input sets, reporting each case separately:

@pytest.mark.parametrize(
    "items, capacity, expected",
    [
        (0, 6, 0),     # nothing to bake
        (1, 6, 1),     # a single pastry still needs a tray
        (6, 6, 1),     # exactly full
        (7, 6, 2),     # one over
        (13, 6, 3),
    ],
    ids=["empty", "one", "exactly-full", "one-over", "typical"],
)
def test_trays_needed(items, capacity, expected):
    assert trays_needed(items, capacity) == expected

The ids appear in the output, as in test_trays_needed[exactly-full] PASSED, so a failure is identified at a glance. Only testing typical values like 13 would never reveal an off-by-one mistake such as items // capacity + 1, which is wrong for exactly 6. For floating-point results, compare with pytest.approx(expected) rather than ==.

pytest.raises asserts that a block raises a particular exception. Add match= to check the message too, which is matched as a regular expression:

def test_negative_items_are_rejected():
    with pytest.raises(ValueError, match="Invalid tray request"):
        trays_needed(-1, 6)

The test fails if no exception is raised, or if a different type is raised. Keep only the call that should fail inside the with block; anything else that raises the same type would make the test pass for the wrong reason.

Avoid writing your own try/except in tests:

try:
    trays_needed(-1, 6)
except Exception:
    pass          # passes even if the function raised TypeError, or nothing at all

For known, temporary problems, @pytest.mark.xfail(reason="...") marks a test as expected to fail, and @pytest.mark.skipif(condition, reason="...") skips it where it can't run, such as on another operating system. Both show up in the summary, so they don't go unnoticed.

Task: write parametrized pytest cases for the tray function and a raises test for invalid capacity.

import pytest

def trays_needed(items, capacity):
    if items < 0 or capacity < 1:
        raise ValueError("Invalid tray request")
    return (items + capacity - 1) // capacity

@pytest.mark.parametrize("items, capacity, expected",
                         [(0, 4, 0), (4, 4, 1), (5, 4, 2), (12, 4, 3)])
def test_trays(items, capacity, expected):
    assert trays_needed(items, capacity) == expected

def test_zero_capacity_is_invalid():
    with pytest.raises(ValueError, match="Invalid"):
        trays_needed(3, 0)

Running pytest on this file reports 5 passed tests: four parametrized cases and one raises test. For the worked check, testing an exact capacity boundary exists to detect off-by-one mistakes, where a formula is correct for most inputs but wrong at the edge.

The pytest documentation covers parametrize, raises and discovery rules. Continue with mocking and fixtures. Practise with the Python exercises and Python quiz.