Fixtures, Plugins, and Extensibility

Three test files each open their own database connection, copy the same eight lines of seeding, and — the part that hurts — skip cleanup whenever the test dies before reaching it. One morning the shared staging database has orphan rows and the suite fails for a reason nobody can reproduce. The fix is not more setup methods; it is moving resources into fixtures the runner creates on request and disposes for you.

# conftest.py
import pytest

@pytest.fixture(scope="session")
def app(tmp_path_factory):
    db_url = f"sqlite:///{tmp_path_factory.mktemp('db')}/app.db"
    application = create_app(db_url=db_url)
    run_migrations(application)
    yield application
    application.shutdown()          # runs even if the test failed

@pytest.fixture
def client(app):
    with app.test_client() as c:
        yield c

@pytest.fixture
def authed(client, seed_user):
    token = client.post('/login', json=seed_user).json['token']
    client.headers['Authorization'] = 'Bearer ' + token
    return client

Tests declare what they need by parameter name:

def test_coupon_reduces_total(authed):      # client and app are built transitively
    ...

That signature carries four guarantees that a hand-rolled setUp cannot. Setup is lazy: app is created only if some test in the run actually asks for it, so a pure API file never boots a database. Setup is compositional: authed depends on client depends on app, and pytest builds the graph once in the right order. Teardown is guaranteed: code after yield executes when the test fails, errors, or is interrupted — which is exactly when cleanup matters most — and finalizers run in reverse order of setup so the thing created last is closed first. Setup is visible: a reader of test_coupon_reduces_total(authed) knows the session exists before looking anywhere else, which is the Arrange section doing its job (see Design Patterns in Test Code). Before writing a custom fixture, check what the runner already ships: tmp_path hands every test a fresh directory the runner deletes, monkeypatch.setenv reverts environment changes at teardown, and capsys captures output — all three built on the same setup, hand over, guaranteed-revert shape. Authoring a third database helper instead of checking conftest is how suites end up with parallel helpers nobody trusts.

Scope decides how much of that runs per test:

The rule is the widest scope that preserves isolation. Two constraints keep you honest: a wider-scoped fixture must not depend on a narrower one, or pytest refuses the request with ScopeMismatch; and anything the test mutates belongs at function scope, because a session-scoped cart would make test order matter again — the exact flakiness fixtures were meant to remove. One budget note for CI: under pytest -n 8, session scope runs once per worker process rather than once per run, so a 1.5-second browser fixture costs 8 × session — small numbers multiplied by parallelism still deserve arithmetic.

autouse=True exists for cross-cutting setup only: freezing the clock, resetting a random seed, flushing captured logs. An autouse fixture that silently logs in everyone hides the precondition from the signature, which undoes the visibility benefit.

Interviewers ask "setUp or fixtures?" expecting the four guarantees above — lazy creation, dependency graph, teardown-on-failure, and visible requirements — plus the scope arithmetic. The runner-side version of the same idea, where capabilities plug in without editing test files, is what the last chapter of this topic covers; first, the same fixture model inside Playwright.

A UI suite with 300 tests that each sign in through the login form spends about six minutes of machine time on a flow that never changes. The fix is the same fixture model you know from pytest, expressed through Playwright's test.extend, plus one lever pytest does not have: fixtures can be scoped to a worker, so each parallel worker pays the login cost once instead of once per test.

// tests/fixtures/auth.ts
import { test as base, expect } from '@playwright/test';

type AuthFixtures = { buyer: Buyer; appPage: Page };

export const test = base.extend<AuthFixtures>({
  buyer: [
    async ({}, use) => { await use(createBuyer()); },
    { scope: 'worker' },
  ],

  appPage: async ({ page, buyer }, use) => {
    await page.goto('/login');
    await page.getByLabel('Email').fill(buyer.email);
    await page.getByLabel('Password').fill(buyer.password);
    await page.getByRole('button', { name: 'Sign in' }).click();
    await page.waitForURL('**/dashboard');
    await use(page);            // the test body runs with a signed-in page
  },
});

export { expect };

Tests import test and expect from the fixtures module instead of @playwright/test, and the dependency is again explicit in the signature: test('shows order history', async ({ appPage }) => ...). The arithmetic is the argument: at 1.2 seconds per login, test-scoped sign-in costs 360 seconds across 300 tests; worker scope with 8 workers costs about ten seconds total — the fixture's scope is a performance decision, not a style choice.

When login must be truly shared, Playwright has a stronger mechanism than a worker fixture — a dedicated project that authenticates once and serializes the cookies for everyone:

// playwright.config.ts
projects: [
  { name: 'setup', testMatch: /.*\.setup\.ts/ },
  {
    name: 'chromium',
    dependencies: ['setup'],
    use: { storageState: '.auth/buyer.json' },
  },
]

The setup project writes .auth/buyer.json; every test in the dependent project starts with the session already established, and the file is a CI artifact you can inspect when auth itself misbehaves. Options ride the same rails: test.use({ storageState: '.auth/admin.json' }) inside a describe block switches identity for one suite only, and viewport, baseURL, and permissions are fixtures too — a config knob and a login session travel through identical mechanics. There is also a cheaper login: post credentials to the API (request.post('/login')) in tens of milliseconds, write the returned token into storageState yourself, and reserve the 1.2-second UI form flow for the handful of tests that actually assert the login form. Choose by lifetime: worker fixture when the session must differ per worker (parallel writes to one account are a flake source), setup project when one identity serves the whole run. Worker-scoped fixtures tear down when the worker finishes, not when a test ends — close API contexts, delete seeded accounts, and flush caches there, or parallel workers will race a cleanup written for a single-process world.

Two habits keep the extension healthy. Fixtures compose — add adminPage alongside appPage, both depending on shared helpers, rather than one mega-fixture that branches on a flag. And auto: true is reserved for genuinely universal behavior (a fixture attaching screenshots to every test); an auto-login fixture applied to API-only specs wastes seconds and confuses readers about which tests are authenticated.

Playwright's fixture objects also carry configuration: test.use({ baseURL, trace: 'on-first-retry' }) scopes options to a describe block without touching globals. The pattern generalizes: capabilities arrive through declared extension points, not through edits to every file — and once teams want retries, tags, and custom reporting bolted on the same way, the runner's plugin surface becomes the place to work, which is the final chapter here.

Requirements keep arriving that sound global: capture a screenshot whenever a test fails, accept --browser=firefox from the command line, tag a smoke subset, post a summary to Slack. Each one tempts you to edit every test file. Runners expose hooks precisely so these land in one place — a plugin — and the core suite stays untouched.

pytest's hook for failure capture is pytest_runtest_makereport, which runs at the moment the test's call phase finishes:

import pytest

@pytest.hookimpl(hookwrapper=True)
def pytest_runtest_makereport(item, call):
    outcome = yield
    report = outcome.get_result()
    if report.when == 'call' and report.failed:
        driver = item.funcargs.get('driver')
        if driver is not None:
            png = driver.get_screenshot_as_png()
            item.add_report_section('call', 'screenshot', 'see attached image')
            # allure.attach(png, name=item.nodeid, attachment_type=allure.png)

Before building a capture hook, check the built-ins: Playwright turns failure evidence into configuration — use: { trace: 'retain-on-failure', screenshot: 'only-on-failure', video: 'retain-on-failure' } — with no code anywhere. Write a custom hook when capture needs domain knowledge: attaching the request body and correlation id, dumping the server-side log excerpt, or serializing application state that no generic screenshot reveals. Knowing the built-in first keeps the plugin layer from reinventing the runner.

Options and markers follow the same rule — declared once, consumed anywhere:

def pytest_addoption(parser):
    parser.addoption('--browser', default='chromium', help='browser for UI runs')

def pytest_configure(config):
    config.addinivalue_line('markers', 'smoke: fast subset run on every PR')

# pytest -m smoke --browser=firefox

Registering the marker matters: unregistered ones raise PytestUnknownMarkWarning and the -m smoke filter silently stops meaning anything once someone typos it. Distribution is the last step — a module gets loaded with -p my_plugin or the pytest11 entry-point group, and allure-pytest is proof the model scales: your favorite report is itself just a plugin.

Playwright and Jest express the same idea through reporters. A reporter sees the whole run and cannot be imported by a single test:

export default class TeamReporter implements Reporter {
  onBegin(config, suite) { this.total = suite.all().length; }
  onTestEnd(test, result) {
    if (result.status !== 'expected') this.failures.push(test.title);
  }
  onEnd(result) {
    this.summary();
    return result.status === 'failed' ? 'failed' : 'passed';
  }
}

// playwright.config.ts
reporter: [['./reporters/team.ts', { webhook: process.env.SLACK_WEBHOOK }]]

Jest does the equivalent with reporters: [['jest-junit', { outputDirectory: 'reports' }]], and a custom module implements onRunComplete(context, results). Options flow through config, never through environment variables read inside tests.

Determinism rules govern every hook. Teardown and after-hooks run in reverse setup order and run even after failures — release browsers, close servers, delete temp dirs there, never in the test body. Hooks execute under parallel workers and retries, so read result.retry instead of assuming attempt one, keep hooks idempotent, and never introduce an assertion there: a reporter signals failure by its exit status, not by throwing mid-run. Finally, write the table — hook or extension point, purpose, owner — into the README, because an extension point nobody documents becomes an extension point nobody uses. In interviews the topic arrives as "how would you add retries, tagging, or a new report without changing every test?" Answer in the runner's vocabulary: declare the option in pytest_addoption, implement behavior in a hook or a reporter, register it in config, document it in the extension table. Naming the real entry points — instead of "I would write a utility class" — is what separates candidates who have extended a runner from candidates who have only used one. With fixtures and plugins in place, the remaining question is how the whole framework holds together and who guards it: Framework Architecture and Ownership comes next, after the matcher-driven assertions of Custom Matchers and Assertions that these reports will display.