Fixtures, parametrize & mocking

1 · Fixtures essential

Here's a pain you've felt if you've written more than a handful of tests. Every test needs a logged-in user, or a populated cart, or a database with three rows in it — so you paste the same eight setup lines into the top of test after test. Then the setup changes (the User constructor gains a required argument) and you're hunting through forty tests fixing the same copy-pasted block forty times. One of them you miss, and now a test is silently building the object the old way. Fixtures exist to kill exactly that.

Think of a fixture as the stagehand for your tests. Before each scene (test), the stagehand walks on, sets up the props — the cart with items in it, the open database connection, the temp folder — hands them to the actor, and after the scene clears them away. The actor (your test) never has to build the set; it just performs against props it was handed. Crucially, the stagehand builds a fresh set for every scene, so nothing one test does can leak into the next.

Precisely: a fixture is a function that produces the setup a test depends on, and hands a new instance to each test that asks for it. In pytest you write @pytest.fixture above the function; a test then requests it simply by naming it as a parameter, and pytest calls the fixture and injects the result — that name-matching is the whole magic, no imports or wiring. The word to hold onto is isolation: because each test receives its own freshly-built object, tests can run in any order, in parallel, or one-at-a-time and still give the same answer. A shared, module-level object would quietly couple your tests together — test A mutates it, test B sees the mutation, and now a failure in B is really a bug in A. That coupling is the single most common cause of "it passes alone but fails in the suite," and fixtures are the cure.

Two mistakes to name before you make them. First, a fixture is not a global variable — if you build one object once and share it, you've thrown away the isolation that was the entire point. Second, don't over-fixture: setup that's used by exactly one test is often clearer written inline; reach for a fixture when the setup is shared or non-trivial. The lab below deliberately shows the fixture as a plain factory function first (so you see there's no framework magic — it's just "a function that returns a fresh object"), with the real @pytest.fixture form noted at the bottom.

fixtures.pyclass Cart:
    def __init__(self): self.items=[]
    def add(self,x,q=1): self.items.append((x,q))
    def total(self): return sum(q for _,q in self.items)

def sample_cart():                    # a fixture = fresh object per test
    c = Cart(); c.add("book"); c.add("pen", 2); return c

assert sample_cart().total() == 3     # each test gets its own -> isolated
assert len(sample_cart().items) == 2
print("fixture-backed tests pass")
# pytest form:  @pytest.fixture def sample_cart(): ...   then def test(sample_cart): ...

fixture-backed tests pass

2 · Parametrize intermediate

Watch how a well-meaning test suite rots. You write test_is_even_two, then copy-paste it into test_is_even_three, then test_is_even_zero, changing one number and one expected value each time. Five near-identical functions later, someone finds a bug at the boundary and you realize you forgot the negative case — so you paste a sixth. Every one of those functions is the same logic with the data hard-wired in, and the test file is now three times longer than the code it tests. The moment you feel yourself copy-pasting a test body and tweaking a literal, that's the signal.

The fix is to separate the test's logic from the test's data. Picture a restaurant health inspector: they don't invent a new procedure for each dish — they run the same checklist against a table of dishes. One procedure, many rows. Parametrization is exactly that: you write the test body once, then feed it a table of (input, expected) rows, and the framework runs the body once per row.

In pytest that's the @pytest.mark.parametrize("n,expected", cases) decorator, and it buys you something a plain loop does not: each row becomes its own reported test. If three rows pass and one fails, you see three green dots and one red one that names the exact failing input — not a single test that dies on the first bad case and hides the rest. That last point is the real payoff and the reason not to just write a for loop with an assert inside: a bare loop stops at the first failure, so if rows 2 and 5 are broken you only ever learn about row 2 until you fix it and re-run. (The lab below uses a loop with a descriptive assert message to simulate the idea offline, and the stdlib subTest in the exercises gives you the "don't stop on first failure" behavior without pytest.)

The common mistake here is over-stuffing the table until the cases become unreadable, or worse, computing the "expected" value with the same code you're testing — which proves nothing, since a bug would corrupt both sides equally. Keep expected values as hand-written literals a human checked, and keep each row to one clear scenario: a couple of normal cases, the boundary (zero, empty, the max), and the nasty edge (a negative, a duplicate). A tight, honest table is worth more than fifty mechanical rows.

param.pydef is_even(n): return n % 2 == 0

cases = [(2, True), (3, False), (0, True), (-4, True), (7, False)]
for n, expected in cases:
    assert is_even(n) == expected, f"failed for {n}"
print(f"all {len(cases)} parametrized cases pass")
# pytest form:  @pytest.mark.parametrize("n,expected", cases) def test_is_even(n,expected): ...

all 5 parametrized cases pass

3 · Mocking advanced

Tests must be fast and deterministic, but real code calls slow/unpredictable things. Mocking replaces them with fakes you control. unittest.mock is stdlib — runs offline.

Picture the test suite you dread. It hits a real payment sandbox, so it's slow — ninety seconds a run. It reads the live clock, so a test that checks "token expires after 60s" passes at 2pm and fails at 2am. It calls a third-party API that goes down for maintenance every Sunday, so your CI turns red for reasons that have nothing to do with your code. These aren't bugs in your logic — they're your test reaching out and touching the messy, slow, unpredictable outside world. Mocking is how you cut those wires.

The mental model is a flight simulator. A trainee pilot doesn't practice engine-failure drills in a real 747 over a real city — they sit in a simulator where the instructor can, on command, make an engine "fail," freeze the weather, or set the fuel gauge to exactly 12%. The cockpit is real; the world outside is a controllable fake. A mock is that fake world for your code: it stands in for the collaborator (the API client, the clock, the file system) and lets you dictate exactly what it returns — and, unlike the real thing, it records every call so you can inspect afterward how your code used it.

Concretely, unittest.mock gives you two moves you'll use constantly. patch (as a with block or a decorator) temporarily swaps a real name for a fake for the duration of that block, then restores the original automatically — so the fake never leaks into other tests. A Mock object, meanwhile, is a shape-shifter: any attribute or method you call on it exists and returns another Mock, and you steer it with return_value (or side_effect to make it raise). Because it logs its calls, you can then assert on behavior: assert_called_once() proves your code invoked the collaborator exactly once — not zero times (it silently skipped the call) and not five times (an accidental loop). That distinction matters: a return-value check tells you what came back; a call assertion tells you how your code interacted with the world.

The classic trap — the one this whole chapter builds toward — is patching the wrong name. Python looks up names where they're used, not where they're defined, so if mymodule does from time import time, you must patch mymodule.time, not time.time; patch the definition and your fake never gets seen. And the deeper lesson lurking under all of it: if a test needs heaps of patching to isolate one function, that's not a mocking skill you're missing — it's your design telling you the function is tangled up with its dependencies. We'll cash that observation out in §5.

mock.pyfrom unittest.mock import patch

def get_username(user_id, client):
    return client.fetch(user_id)["name"]      # client is some API wrapper

# patch the collaborator so no real call happens:
class RealClient:
    def fetch(self, uid): raise RuntimeError("would hit the network!")

with patch.object(RealClient, "fetch", return_value={"name": "Ava"}) as m:
    assert get_username(1, RealClient()) == "Ava"
    m.assert_called_once()
print("mocked call verified, no network")

mocked call verified, no network

mock_time.pyfrom unittest.mock import patch
import time
def cache_key(): return f"key-{int(time.time())}"

with patch("time.time", return_value=1000.0):
    assert cache_key() == "key-1000"
print("time frozen -> deterministic")

time frozen -> deterministic

4 · Professional — fixtures with teardown professional

Here's the failure that teaches this lesson the hard way. Your test suite opens a database connection, or a temp file, or a socket, in each test's setup. It works fine — for a while. Then, weeks later, CI starts failing intermittently with "too many open files" or "database is locked." The cause: every test opened a resource and none of them ever closed it, so they leaked, one per test, until the process ran out. Or worse — a test wrote a temp file, the next test found it already there, and now tests pass or fail depending on what ran before them. Setup got all the attention; nobody wrote the cleanup.

A fixture, properly understood, has two halves: the setup that builds the resource, and the teardown that tears it down again. Think of a chemistry lab. Before the experiment you set out clean glassware; after it, you wash everything and put it away — because the next student needs the bench exactly as clean as you found it. Teardown is that wash-up. Skip it and the residue from your experiment contaminates the next one. The whole promise of isolation — each test starting from a known clean slate — depends on teardown running reliably, even when the test in the middle blows up.

Pytest expresses this beautifully with yield: a fixture that does its setup, yields the resource to the test, and then runs whatever comes after the yield as teardown. The yield is the hand-off point — everything above it is "before the test," everything below it is "after the test, guaranteed." The stdlib unittest equivalent is setUp/tearDown, or more robustly addCleanup, which registers a cleanup the instant a resource exists (so it fires even if setup only half-completes — a real edge case tearDown can miss). The subtle point to internalize: teardown must run on the failure path, not just the happy path, which is exactly why frameworks provide these hooks instead of letting you tack a .close() at the end of the test — that final line never executes if an assertion above it raises.

One tip that dodges the whole problem when you can: prefer resources that clean up themselves. The lab below uses SQLite's :memory: database — it lives entirely in RAM and simply evaporates when the connection closes or the process ends, so there's no file on disk to leave behind and no other test it can contaminate. When a genuinely external resource (a real file, a container, a cloud bucket) is unavoidable, that's when disciplined teardown earns its keep.

teardown.pyimport sqlite3

def make_db():                         # fixture with teardown via context
    conn = sqlite3.connect(":memory:")
    conn.execute("CREATE TABLE t (id INTEGER PRIMARY KEY, name TEXT)")
    return conn

db = make_db()
db.execute("INSERT INTO t(name) VALUES ('ava')")
assert db.execute("SELECT COUNT(*) FROM t").fetchone()[0] == 1
db.close()                             # teardown
print("db fixture works and is isolated per test")
# pytest form uses `yield` for teardown:  @pytest.fixture def db(): c=...; yield c; c.close()

db fixture works and is isolated per test

5 · Tech-lead — design for testability tech-lead

If code is hard to mock, the design is the problem. A lead pushes dependency injection (SD3) so external calls are swappable — making the whole codebase testable without monkey-patching internals.

Here's the reframe that turns a testing chapter into a design chapter. In §3 you learned to patch the outside world. But if you find yourself patching three modules, freezing the clock, and monkeypatching a private attribute just to test one function, stop and listen to what the pain is telling you. Fighting the code to test it is not a sign you need better mocking tricks — it's the code screaming that it's too entangled with its dependencies. Difficulty of testing is one of the most honest, hardest-to-fake signals of design quality we have. Easy-to-test code is almost always well-structured code, and vice versa; the test is the canary in the coal mine.

The root cause is almost always the same: a function or class that reaches out and builds its own collaborators. When ReportBad calls random.random() internally, or a function does db = RealDatabase() on its own, it has welded itself to a specific, unpredictable, slow dependency. There's no seam — no place for a test to slip a fake in. Your only recourse is patching, which is really you prying open a seam by force from the outside.

The fix is dependency injection, and the idea is disarmingly simple: don't let an object build its dependencies — hand them to it. Think of a power tool with a standard socket. A good drill doesn't have one bit welded on; it accepts any bit you push into the chuck. In production you insert the real "bit" (the live database, the wall-clock time); in a test you insert a tiny fake bit (a lambda: 1000 for the clock, a hand-written FakeStore that just records what it was told). The drill's logic is identical either way, because it only ever depended on the socket — the interface — not on any specific bit. That socket is the "seam," and injection is the act of putting seams where the outside world touches your code.

The payoff compounds beyond one test. Injected fakes are usually plain objects and lambdas — no patch, no Mock, no fragile string paths to get right, so the tests are shorter and don't break when you rename an internal. Notice the mistake this quietly avoids: over-mocking. Heavy mocking is a design smell, not a testing technique to master — the more you reach for it, the louder the code is asking to be refactored. As a tech lead, the highest-leverage move isn't writing better tests; it's designing code with clean seams so the whole team writes easy tests by default. The best test infrastructure a codebase can have is a testable design.

testable_design.py# HARD to test: creates its own dependency internally
class ReportBad:
    def run(self):
        import random
        return random.random()          # non-deterministic, can't assert

# EASY to test: dependency injected
class Report:
    def __init__(self, clock, source):   # inject collaborators
        self.clock, self.source = clock, source
    def run(self):
        return {"at": self.clock(), "data": self.source()}

# test with fakes — fully deterministic, no patching:
r = Report(clock=lambda: 1000, source=lambda: [1, 2, 3])
assert r.run() == {"at": 1000, "data": [1, 2, 3]}
print("injected design tested with zero mocking machinery")

injected design tested with zero mocking machinery

import unittest

class Cart:
    def __init__(self): self.items = []
    def add(self, x): self.items.append(x)
    def total(self): return len(self.items)

class TestCart(unittest.TestCase):
    def setUp(self):
        self.cart = Cart()          # fresh per test = the fixture
    def test_starts_empty(self):
        self.assertEqual(self.cart.total(), 0)
    def test_add(self):
        self.cart.add("x")
        self.assertEqual(self.cart.total(), 1)

if __name__ == "__main__":
    unittest.main(verbosity=2)      # 2 tests OK, no cross-talk

import unittest

def is_even(n): return n % 2 == 0

class TestEven(unittest.TestCase):
    CASES = [(0, True), (1, False), (2, True), (-3, False)]
    def test_is_even(self):
        for n, expected in self.CASES:
            with self.subTest(n=n):
                self.assertEqual(is_even(n), expected)

if __name__ == "__main__":
    unittest.main(verbosity=2)     # one method, 4 sub-cases; failures name n

import unittest
from unittest.mock import Mock

def fetch_user(client, uid):
    resp = client.get(f"/users/{uid}")     # would be a real HTTP call
    return resp["name"].upper()

class TestFetch(unittest.TestCase):
    def test_uses_client_and_transforms(self):
        client = Mock()
        client.get.return_value = {"name": "ada"}   # fake the network
        self.assertEqual(fetch_user(client, 7), "ADA")
        client.get.assert_called_once_with("/users/7")

if __name__ == "__main__":
    unittest.main(verbosity=2)     # fast, offline, deterministic

import unittest, time
from unittest.mock import patch

def is_expired(issued_at, ttl=60):
    return time.time() - issued_at > ttl

class TestExpiry(unittest.TestCase):
    @patch("time.time", return_value=1000.0)
    def test_not_expired(self, _mock):
        self.assertFalse(is_expired(issued_at=990, ttl=60))   # 10s old
    @patch("time.time", return_value=1000.0)
    def test_expired(self, _mock):
        self.assertTrue(is_expired(issued_at=900, ttl=60))    # 100s old

if __name__ == "__main__":
    unittest.main(verbosity=2)     # both deterministic regardless of real clock

import unittest, tempfile, os

class TestWithTempFile(unittest.TestCase):
    def setUp(self):
        fd, self.path = tempfile.mkstemp()
        os.close(fd)
        self.addCleanup(self._remove)     # runs even if the test raises
    def _remove(self):
        if os.path.exists(self.path):
            os.remove(self.path)
    def test_writes(self):
        with open(self.path, "w") as f: f.write("hi")
        with open(self.path) as f:
            self.assertEqual(f.read(), "hi")

if __name__ == "__main__":
    unittest.main(verbosity=2)     # temp file created, used, then cleaned up

import unittest

# HARD to test: creates its own clock + store internally
# def charge(amount): db = RealDB(); db.write(time.time(), amount)

# TESTABLE: seams are parameters
def charge(amount, clock, store):
    store.write(clock(), amount)

class FakeStore:
    def __init__(self): self.rows = []
    def write(self, ts, amt): self.rows.append((ts, amt))

class TestCharge(unittest.TestCase):
    def test_records_with_time(self):
        store = FakeStore()
        charge(42, clock=lambda: 1000.0, store=store)
        self.assertEqual(store.rows, [(1000.0, 42)])

if __name__ == "__main__":
    unittest.main(verbosity=2)     # no patching needed; seams are explicit

Knowledge check check yourself