Test Fixtures

What are Test Fixtures?

Fixtures are functions that run before (and sometimes after) your test functions. They provide a fixed baseline for your tests by setting up necessary preconditions like test data, database connections, or initialized objects.

In pytest, fixtures are defined using the @pytest.fixture decorator and can be shared across multiple tests.

Why Use Fixtures?

Reusability

Write setup code once and use it across multiple tests

Clean Code

Keep test functions focused on testing, not setup

Dependency Injection

Automatically provide dependencies to tests that need them

Scope Control

Control when fixtures are created and destroyed

Real Fixtures from Our Test Suite

Let’s examine the actual fixtures defined in our project:

import json
from pathlib import Path
import pytest

@pytest.fixture(scope="session")
def users():
    """
    Loads testData/users.json and returns a dict.
    Accessible in any test as the 'users' fixture.
    """
    root = Path(__file__).parent.parent  # go from /tests to project root
    data_path = root / "testData" / "users.json"
    with data_path.open(encoding="utf-8") as f:
        return json.load(f)

Understanding Fixture Scopes

Fixtures can have different scopes that control how often they’re created:

session
function
module
class

Created once per test session

@pytest.fixture(scope="session")
def users():
    # Created once, shared across all tests
    data_path = Path(__file__).parent.parent / "testData" / "users.json"
    with data_path.open(encoding="utf-8") as f:
        return json.load(f)

Use when:

Loading static data that doesn’t change
Setting up expensive resources
Data is read-only

Our users fixture uses session scope because the JSON data is loaded once and never modified.

Created for each test function (default)

@pytest.fixture  # or scope="function"
def login_page(page):
    # Created fresh for each test
    return LoginPage(page)

Use when:

Each test needs a fresh instance
Tests modify the fixture’s state
Most common scope for test isolation

Created once per module (.py file)

@pytest.fixture(scope="module")
def database_connection():
    # Created once per test file
    conn = create_connection()
    yield conn
    conn.close()

Use when:

Sharing expensive setup across tests in one file
Need cleanup after all tests in module

Created once per test class

@pytest.fixture(scope="class")
def browser_context():
    # Created once per test class
    context = browser.new_context()
    yield context
    context.close()

Use when:

Testing class methods that share state
Class-level setup and teardown needed

Using Fixtures in Tests

Here are real examples from our test suite showing fixture usage:

Using User Data
Using Environment Variables
Multiple Fixtures

tests/test_functionalities.py

from pages.login import LoginPage

def test_with_testdata(page, users):
    login_page = LoginPage(page)
    login_page.navigate()
    login_page.login(users["validUser"]["username"], users["validUser"]["password"])

    assert page.get_by_test_id("title").is_visible

How it works:

Test declares users parameter
pytest automatically calls the users() fixture
Fixture loads JSON data
Test receives the data dictionary
Test accesses nested values: users["validUser"]["username"]

The page parameter is also a fixture, provided by Playwright’s pytest plugin.

tests/test_functionalities.py

from pages.login import LoginPage

def test_login_with_env_vars(page, creds):
    login_page = LoginPage(page)
    login_page.navigate()
    login_page.login(creds["valid_user"], creds["pwd"])

    assert page.get_by_test_id("title").is_visible

Security benefit:

Credentials stored in .env file (not committed to git)
Loaded via load_dotenv() in conftest.py
Tests access credentials without hardcoding

The fixture raises a RuntimeError if environment variables are missing, causing tests to fail fast with a clear error message.

def test_complex_scenario(page, users, creds):
    # Can use multiple fixtures in one test
    # Each is automatically provided by pytest
    pass

Fixture dependency:

Fixtures can depend on other fixtures
pytest resolves dependencies automatically
Order of parameters doesn’t matter

The conftest.py File

conftest.py is a special pytest file where you define fixtures that should be available to all tests in the directory and subdirectories.

Our Project Structure

source/
├── tests/
│   ├── conftest.py          # Fixtures available to all tests
│   ├── test_login.py
│   ├── test_functionalities.py
│   └── test_assertions.py
├── pages/
│   ├── login.py
│   └── cart_page.py
└── testData/
    └── users.json           # Loaded by users fixture

Complete conftest.py Breakdown

Imports and Setup

import os
from pathlib import Path
import pytest
from dotenv import load_dotenv
import json

Path: For cross-platform file path handling
pytest: For fixture decorators
dotenv: For loading environment variables
json: For parsing JSON test data

Users Fixture

@pytest.fixture(scope="session")
def users():
    """
    Loads testData/users.json and returns a dict.
    Accessible in any test as the 'users' fixture.
    """
    root = Path(__file__).parent.parent  # go from /tests to project root
    data_path = root / "testData" / "users.json"
    with data_path.open(encoding="utf-8") as f:
        return json.load(f)

Key points:

Uses Path(__file__).parent.parent to navigate to project root
Opens and parses JSON file
Returns dictionary structure from users.json:line_1
Session scope means it loads once for all tests

Credentials Fixture

load_dotenv(dotenv_path=Path(__file__).parent.parent / ".env")

@pytest.fixture(scope="session")
def creds():
    """
    Provides credentials from environment variables.
    Fails early with a clear message if missing.
    """
    user = os.getenv("USERNAME")
    pwd = os.getenv("PASSWORD")
    if not user or not pwd:
        raise RuntimeError("Missing USERNAME/PASSWORD in environment. ")
    return {"valid_user": user, "pwd": pwd}

Key points:

load_dotenv() called at module level (runs once on import)
Reads from .env file in project root
Validates that required variables exist
Returns dictionary with consistent key names

Advanced Fixture Patterns

Fixture with Teardown
Fixture Factory
Fixture Dependencies
Parametrized Fixtures

Use yield for setup and teardown:

@pytest.fixture
def logged_in_page(page):
    # Setup: Login before test
    login_page = LoginPage(page)
    login_page.navigate()
    login_page.login("standard_user", "secret_sauce")
    
    yield page  # Test runs here
    
    # Teardown: Logout after test
    page.locator("#logout_sidebar_link").click()

Usage:

def test_cart_actions(logged_in_page):
    # Page is already logged in
    cart = CartPage(logged_in_page)
    cart.add_product("sauce-labs-backpack")
    # After test, logout happens automatically

Return a function to create multiple instances:

@pytest.fixture
def make_cart_page(page):
    def _make_cart():
        return CartPage(page)
    return _make_cart

def test_multiple_carts(make_cart_page):
    cart1 = make_cart_page()
    cart2 = make_cart_page()
    # Can create multiple instances

Fixtures can use other fixtures:

@pytest.fixture
def login_page(page):
    return LoginPage(page)

@pytest.fixture
def logged_in_session(login_page, users):
    # Uses both login_page and users fixtures
    login_page.navigate()
    login_page.login(
        users["validUser"]["username"],
        users["validUser"]["password"]
    )
    return login_page.page

Create fixtures with multiple values:

@pytest.fixture(params=[
    "standard_user",
    "performance_glitch_user",
    "visual_user"
])
def username(request):
    return request.param

def test_login_variations(page, username):
    # Test runs 3 times, once for each username
    login_page = LoginPage(page)
    login_page.login(username, "secret_sauce")

Best Practices

Use Descriptive Names

# Good: Clear what it provides
@pytest.fixture
def valid_user_credentials():
    return {"username": "standard_user", "password": "secret_sauce"}

# Avoid: Vague naming
@pytest.fixture
def data():
    return {"username": "standard_user", "password": "secret_sauce"}

Choose Appropriate Scope

# Session: Static data (fast, but shared)
@pytest.fixture(scope="session")
def users():
    return load_json("users.json")

# Function: Fresh instances (slower, but isolated)
@pytest.fixture
def cart_page(page):
    return CartPage(page)

Document Your Fixtures

@pytest.fixture(scope="session")
def users():
    """
    Loads testData/users.json and returns a dict.
    Accessible in any test as the 'users' fixture.
    
    Structure:
    {
        "validUser": {"username": "...", "password": "..."},
        "invalidUser": {"username": "...", "password": "..."}
    }
    """
    # implementation

Fail Fast on Errors

@pytest.fixture(scope="session")
def creds():
    user = os.getenv("USERNAME")
    pwd = os.getenv("PASSWORD")
    if not user or not pwd:
        # Clear error message
        raise RuntimeError("Missing USERNAME/PASSWORD in environment. ")
    return {"valid_user": user, "pwd": pwd}

Common Pitfalls

Mutable Fixture Data with Session Scope

# Dangerous: Session-scoped mutable data
@pytest.fixture(scope="session")
def user_list():
    return ["user1", "user2"]  # Same list shared across tests

def test_modify_users(user_list):
    user_list.append("user3")  # Affects other tests!

Solution: Use function scope for mutable data or return copies.

Forgetting to Use Fixture Parameters

# Wrong: Fixture defined but not used
@pytest.fixture
def users():
    return load_json("users.json")

def test_login(page):  # Missing 'users' parameter
    # Can't access users fixture!

Solution: Add fixture name as test parameter: def test_login(page, users):

Get Started

Core Concepts

Writing Tests

Advanced

What are Test Fixtures?

Why Use Fixtures?

Reusability

Clean Code

Dependency Injection

Scope Control

Real Fixtures from Our Test Suite

Understanding Fixture Scopes

Using Fixtures in Tests

The conftest.py File

Our Project Structure

Complete conftest.py Breakdown

Advanced Fixture Patterns

Best Practices

Common Pitfalls

Next Steps

Page Object Model

Test Data

Build docs developers (and LLMs) love

Get Started

Core Concepts

Writing Tests

Advanced

​What are Test Fixtures?

​Why Use Fixtures?

Reusability

Clean Code

Dependency Injection

Scope Control

​Real Fixtures from Our Test Suite

​Understanding Fixture Scopes

​Using Fixtures in Tests

​The conftest.py File

​Our Project Structure

​Complete conftest.py Breakdown

​Advanced Fixture Patterns

​Best Practices

​Common Pitfalls

​Next Steps

Page Object Model

Test Data

Build docs developers (and LLMs) love

What are Test Fixtures?

Why Use Fixtures?

Real Fixtures from Our Test Suite

Understanding Fixture Scopes

Using Fixtures in Tests

The conftest.py File

Our Project Structure

Complete conftest.py Breakdown

Advanced Fixture Patterns

Best Practices

Common Pitfalls

Next Steps