Fixtures — Setup and Teardown

The Core Concept: Dependency Injection

In standard testing frameworks, setup often relies on global methods like 'setup_method' which creates implicit coupling. Pytest fixtures revolutionize this by using dependency injection; a test function explicitly requests a fixture by naming it as an argument. The framework performs an inspection of the function signature to determine which fixtures need to be resolved before the test body runs. This inversion of control is powerful because it keeps the test logic focused solely on the assertion being performed rather than the environment orchestration. When you request a fixture, the framework ensures the setup code runs exactly once for that scope before the test commences. This creates a predictable lifecycle where the test environment is built just-in-time, preventing state contamination between independent test cases. By keeping the fixtures in a central location, you ensure that every test follows the same rigorous initialization process, which significantly reduces the maintenance burden as your project scales to hundreds or thousands of tests.

import pytest

# Define a simple fixture using the decorator
@pytest.fixture
def user_data():
    # Setup: Create a common data structure
    return {"id": 1, "name": "Alice"}

def test_user_name(user_data):
    # Injection: The framework passes the fixture result here
    assert user_data["name"] == "Alice"

Handling Teardown with Yield

Managing resources often requires two phases: acquiring the resource before the test and releasing it afterwards. While some frameworks force you to write separate teardown methods, pytest utilizes a clean, procedural approach using the 'yield' statement. When a fixture hits a 'yield', it pauses its execution and passes control to the test function. Once the test completes, the framework resumes execution of the fixture at the line immediately following the 'yield'. This block is the dedicated place for teardown logic, such as closing file handles, rolling back database transactions, or resetting global state. This pattern is essential because it guarantees that resources are reclaimed even if the test fails or raises an exception. By centralizing the setup and teardown into a single function, you keep your test code DRY and ensure that your environment is returned to a pristine state, preventing side effects from leaking into subsequent test executions.

import pytest
import os

@pytest.fixture
def temp_file():
    # Setup: Create the resource
    with open("test.txt", "w") as f:
        f.write("content")
    yield "test.txt" # Provide the path to the test
    # Teardown: Cleanup happens after the test finishes
    if os.path.exists("test.txt"):
        os.remove("test.txt")

def test_file_read(temp_file):
    assert os.path.exists(temp_file)

Fixture Scoping: Controlling Lifecycle

Efficiency in testing is often determined by how many times you recreate heavy resources. By default, fixtures have 'function' scope, meaning they are created and destroyed for every single test. However, you can change this to 'module', 'class', or 'session' scopes. A 'session' scoped fixture, for instance, is initialized once for the entire test run. This is invaluable when connecting to a database or launching a browser instance where the overhead of startup is significant. You must be careful, however: persistent fixtures share state across tests. If one test modifies a database record created by a session-scoped fixture, that change persists for all subsequent tests. Consequently, you must design your tests to be either stateless or responsible for explicitly cleaning up their own modifications. Properly choosing the scope is the primary tool in your belt for balancing test execution speed against the risk of cross-test interference.

import pytest

@pytest.fixture(scope="session")
def database_connection():
    # Setup: Expensive connection process
    db = "Connected"
    yield db
    # Teardown: Only runs once after all tests conclude
    print("Disconnecting...")

def test_one(database_connection):
    assert database_connection == "Connected"

Fixture Composition and Dependency

Fixtures are not just isolated units; they can depend on each other, allowing you to build complex test environments through composition. If a fixture requires another, it simply requests it as an argument just like a test function would. Pytest automatically resolves the dependency graph, ensuring that the necessary upstream fixtures are set up first. This modularity allows you to create highly reusable base fixtures that represent specific layers of your application. For instance, a 'db_connection' fixture might depend on a 'config_loader' fixture, which in turn depends on an 'env_vars' fixture. By nesting these responsibilities, you avoid massive setup functions that are difficult to debug. If a low-level dependency fails to set up, the dependent fixtures are skipped, which provides clear feedback about where the environment failure originated. This tree-like structure encourages you to think about your infrastructure as distinct, stackable building blocks rather than one monolithic setup script.

import pytest

@pytest.fixture
def config():
    return {"host": "localhost"}

@pytest.fixture
def api_client(config):
    # This fixture uses the 'config' fixture internally
    return f"Client at {config['host']}"

def test_api(api_client):
    assert "localhost" in api_client

Using Autouse for Global Concerns

Occasionally, you need a fixture to run for every single test in a module or folder without explicitly requesting it in the test parameters. This is achieved via the 'autouse=True' flag. This is particularly useful for global requirements, such as forcing a specific logging level for all tests or ensuring a directory is cleaned before any test execution starts. While it might seem convenient, overuse of 'autouse' can make test behavior opaque, as it becomes harder to trace which fixtures are affecting the environment at any given time. Use this sparingly for truly universal prerequisites. When implemented correctly, it removes the clutter of passing unused fixture arguments into hundreds of functions. It serves as a guardrail, ensuring that essential infrastructure is always active, providing a standardized environment that is immune to developers forgetting to include a specific, mandatory setup component in their individual test signatures.

import pytest

@pytest.fixture(autouse=True)
def set_logging_level():
    # This runs for every test automatically
    print("Logging level set to DEBUG")
    yield

def test_logic():
    assert True # Logging is already configured

Interview questions

All pytest & Testing interview questions →

Check yourself

Take the full pytest & Testing quiz →