pytest

Most testing frameworks borrow xUnit's setUp/tearDown model: define methods on a class, the framework calls them before and after each test. pytest replaces that with fixtures.

import pytest

@pytest.fixture
def db():
    conn = open_connection()
    yield conn
    conn.close()

def test_inserts_user(db):
    db.execute("INSERT INTO users VALUES (1, 'alice')")
    assert db.query("SELECT name FROM users WHERE id = 1") == "alice"

A fixture is a function decorated with @pytest.fixture. Any test that lists the fixture's name as a parameter receives the fixture's return value. The yield statement separates setup from teardown. There is no inheritance, no base class, no self reference. Fixtures can depend on other fixtures, can be scoped (function, module, session), and can take parameters via @pytest.fixture(params=[...]).

This is what most engineers stay for. Fixture composition turns out to be one of the cleaner ways to handle test state at scale, especially in test suites that touch databases, HTTP services, or filesystem layouts. Once a fixture exists, every test that needs the same setup just lists it as a parameter and gets it.

For testing the same logic across many cases, @pytest.mark.parametrize is the canonical pattern.

import pytest

@pytest.mark.parametrize("input,expected", [
    ("name@example.com", True),
    ("not-an-email", False),
    ("", False),
    ("@example.com", False),
])
def test_validate_email(input, expected):
    assert is_valid_email(input) == expected

pytest runs the test function four times, once per row, and reports each as a separate test. When one case fails, the failure output shows you which input caused it. The alternative (a single test with a for loop) loses that resolution: the first failing case stops the test, and you have no easy way to know which other cases would have failed.

pytest's plugin API is part of why the framework outlasted its competitors. Most teams end up depending on a small handful of plugins.

• pytest-asyncio. Teach pytest how to run async def tests as coroutines. Standard for any modern Python project using asyncio.
• pytest-xdist. Run tests in parallel across CPU cores or remote workers. The first thing you reach for when CI is slow.
• pytest-cov. Coverage reporting integrated with the test run. Outputs a percentage, an HTML report, and (importantly for CI) a coverage diff per pull request.
• pytest-mock. A thin wrapper around unittest.mock that exposes it as a fixture, so mocks clean up automatically at test end.
• pytest-django, pytest-flask, pytest-fastapi. Framework-specific helpers (test client, database fixtures, settings overrides). Worth using over rolling your own.
• pytest-testmon. Selective test execution: only run tests affected by the changes since the last run. Substantial CI time savings on large suites.
• pytest-rerunfailures. Automatic retries on test failure. Useful as a temporary mitigation, dangerous as a permanent solution: it masks flakes instead of fixing them.

A pytest suite that takes 30 seconds for 50 tests will take 30 minutes for 5,000 tests if nothing changes. The factor that determines whether the project survives that growth is how the suite is split.

Mark fast and slow tests

Add a @pytest.mark.slow marker to anything that touches a database, a network, or a real subprocess. In CI, run pytest -m "not slow" on every push, and pytest (everything) in a second stage at merge time. This is the most common shape of two-step CI, applied to pytest.

Parallelize with pytest-xdist

pytest -n auto shards the test set across CPU cores. On a CI runner with 8 cores, a five-minute serial suite often drops to under a minute. The trade-off is that tests must be independent, which catches teams whose tests share fixtures with implicit ordering assumptions.

Cache the slow fixtures

Most pytest suites that get slow get slow because of the fixtures, not the tests. A fixture that recreates the database schema for every test is several times slower than one that wraps each test in a transaction. Move expensive fixtures to session scope when possible. Wrap database calls in transactions that roll back. Reuse the same Docker container across the test session.

Once a pytest suite passes a few thousand tests, a stable set of flakiness patterns shows up. None of them are about pytest itself; they are about the test code on top of it.

• Shared mutable state across tests. A global, a class attribute, a module-level cache. One test mutates it, the next test reads the mutation, the order in which the tests run starts to matter.
• Time-dependent assertions. datetime.now() compared against a fixed value, sleep-based synchronization, timeouts that pass on a fast machine and fail on a slow one. Use freezegun or inject the clock.
• asyncio event loop leakage. Tasks scheduled in one test continue into the next when the loop is not torn down properly. pytest-asyncio's default loop scope catches most of this; explicit cleanups handle the rest.
• Order-dependent fixtures. A fixture that yields a connection, mutates a row, and rolls back at teardown. If two tests share the same row, one of them sees the partial state of the other.
• Network calls hidden inside libraries. A test that should be a unit test, but the library under test reaches for a remote service during import. Add --disable-socket to make this fail loudly.

For the broader framework-level patterns and how to fix them, see the pytest flaky tests guide.