Proving It Works, Not Just Believing It

Eyeballing output scales fine for one function with one path through it. It stops scaling the moment a function has a branch, an edge case, or a second person changing it three months later — you cannot re-read fifty print statements by hand every time, and after the second or third time, nobody does. A test is that eyeballing, written down once and run automatically forever after.

$ >>> def add(a, b):$ ...     return a + b$ ...$ >>> assert add(2, 3) == 5$ >>> assert add(2, 3) == 6$ Traceback (most recent call last):  ...$ AssertionError

assert condition does nothing at all if condition is true, and raises an AssertionError the instant it is false. That is the entire mechanism every testing tool in Python — including pytest — is ultimately built on top of.

pytest is what turns a scattering of asserts into a suite you run with one command. It looks for files named test_*.py and functions inside them named test_*, runs every one it finds, and reports which passed and which raised — no test runner of your own to write.

$ $ pytest$ test_largest.py::test_returns_the_maximum_value PASSED$ test_largest.py::test_empty_list_returns_none PASSED $ 2 passed in 0.01s

A test that mixes setup, the call being tested, and the check into one tangled block is hard to read back later. Most well-written tests fall into the same three-part shape, in the same order, every time.

1. 1
   Arrange

   Set up whatever the test needs — here, just the two numbers being added.

2. 2
   Act

   Call the one thing actually being tested, and nothing else.

3. 3
   Assert

   Check the result against exactly one expected answer.

def test_add_negative_numbers():    # Arrange    a, b = -2, -3     # Act    result = add(a, b)     # Assert    assert result == -5

The comments are not required — the value of the shape is that it usually gives each test exactly one thing to prove. A test that will not fit cleanly into arrange, act, assert is often a sign it is quietly trying to check two behaviours at once, and would read more clearly split into two tests instead of one.

A test is only proof of something if it is possible for it to fail. Check three cases below, each testing a small function for finding the largest number in a list — see which ones actually earn their place.

Case 3 is one example of a whole category worth writing on purpose: the empty collection, the single-item collection, the negative number, the duplicate value, the input right on the boundary of a condition. None of these show up if you only ever run the "normal" case by hand and read the output — they are precisely the inputs a human tester tends to skip, and precisely the ones most likely to break a real function later.

def test_largest():    assert largest([3, 1, 4]) == 4 def test_returns_the_maximum_value():    assert largest([3, 1, 4]) == 4 def test_empty_list_returns_none():    assert largest([]) is None

test_largest says only which function is involved. test_returns_the_maximum_value says what the test actually proves — when it fails months later, the name alone tells you what broke, before you have read a single line of the assertion.

Several tests often need the same setup — the same sample data, the same open file, the same list to test against. Repeating that setup in every test function works, but a pytest.fixture lets you write it once and have pytest hand it to any test that asks for it.

import pytest @pytest.fixturedef sample_scores():    return [88, 92, 79, 95] def test_average_of_sample_scores(sample_scores):    assert average(sample_scores) == 88.5

sample_scores as a parameter name in test_average_of_sample_scores is not a coincidence — pytest matches a test's parameters against fixture names by that exact name, runs the matching fixture first, and passes in whatever it returned. It is a small piece of machinery, that is rarely useful until the same setup has already been copied into three or four tests.

A coverage tool reports the percentage of lines your test suite actually ran — 100% means every line executed at least once while the tests were running, nothing more specific than that.