pytest fixtures, parametrisation and markers: keeping a suite fast and readable

What it is

A fixture is a function decorated with @pytest.fixture whose returned or yielded value is injected into any test that names it as a parameter; code after yield runs as teardown. Fixtures can request other fixtures, have a scope (function by default, or class, module, package, session), can be autouse, and are shared across files through conftest.py. @pytest.mark.parametrize("a,expected", [...]) runs one function once per case, each reported separately; pytest.param(..., marks=pytest.mark.xfail) marks a single case. Markers such as slow label tests for selection with -m "not slow"; they are registered in the configuration file, and --strict-markers makes an unregistered marker an error.

Why it matters

Fixtures replace copied setup code and setUp inheritance with dependencies visible in the test signature. Parametrisation turns a loop inside a test, which stops at the first failure, into independent cases. Markers let a pull-request run skip slow suites without editing code.

How to apply

• Keep function scope by default; widen to module or session only for expensive, immutable resources (a database container, a compiled model). The documentation's example is an SMTP connection reused within a module. Never mutate a widened fixture inside a test.
• Put a fixture in the nearest conftest.py that covers all its users; a root conftest.py holding everything hides which tests need what.
• Use yield fixtures for teardown, the documented recommended form, so cleanup runs even when the test fails.
• Give parametrised cases readable ids so that -k selection and failure output name the case; prefer one table of inputs and expected outputs to many near-identical functions.
• Register every marker with a description and add --strict-markers to addopts, so @pytest.mark.slwo fails collection instead of silently running.
• Use the built-in tmp_path and monkeypatch fixtures instead of hand-written temporary directories and attribute patching.

Pitfalls

Autouse fixtures hide dependencies; reserve them for truly global concerns such as a fixed clock. Building parametrise lists from the network or a database at import time makes collection slow and flaky. A wider-scoped fixture cannot depend on a narrower-scoped one. The documentation states that marks apply to tests only and have no effect on fixtures.