Most teams do not have a test data problem in the abstract. They have a test ownership problem.

Someone creates data in a fixture because it is convenient. Someone else pushes setup into the UI because it matches a user flow. A third person calls an API because it is faster and more reliable. A few months later, the suite is slow, the failures are hard to diagnose, and nobody can explain which layer is supposed to create what.

My default position is simple: the cheapest setup path that still keeps the test readable, isolated, and debuggable should own the data. That sounds obvious until you are choosing between a Playwright fixture, API setup, or UI steps for every new test. The right answer depends on how much behavior you need to validate in setup, how expensive the path is in CI, and how painful it will be to debug when something breaks.

This is the decision framework I use for a Playwright test data strategy, especially when teams need to balance stable test data patterns with real production-like behavior.

The ownership question is really three questions

When a test needs data, ask these three things:

  1. What is the cheapest reliable way to create the state?
  2. What does the test need to prove about that state creation?
  3. Who should own cleanup and lifecycle, so failures do not poison other tests?

That pushes the decision away from taste and toward operational consequences. In test automation, especially end-to-end testing, setup cost matters because it affects the entire suite, not just the single test you are writing.

If setup is slow, flaky, or hard to reason about, the test becomes expensive even when the assertions are trivial.

I treat data ownership as a tradeoff among three layers:

  • Playwright fixtures, when the data is part of the test harness and should be reusable across tests.
  • API setup, when the system under test already exposes a stable, faster way to create state.
  • UI steps, when the setup is itself a behavior you need to validate, or when the product has no trustworthy backdoor.

The right owner is usually the one that minimizes total maintenance cost, not raw implementation effort.

My default hierarchy

I usually evaluate setup paths in this order:

1. API setup first, when the API is stable and intended for this purpose

If the product exposes a supported API for creating the relevant entities, that is often the best place to create test data. It is faster than UI setup, less brittle than browser-driven flows, and easier to reset between tests.

A common pattern is to create data through the API, then verify the user-facing behavior in Playwright. This keeps the test focused on what matters in the browser without forcing the browser to do work it does not need to do.

import { test, expect } from '@playwright/test';

test('user sees created project', async ({ request, page }) => {
  const project = await request.post('/api/projects', {
    data: { name: 'Alpha', owner: 'qa' }
  });

expect(project.ok()).toBeTruthy();

await page.goto(‘/projects’); await expect(page.getByText(‘Alpha’)).toBeVisible(); });

This works well when the API endpoint is deterministic, authenticated in a repeatable way, and aligned with the object model the tests need. It fails when the API is eventually consistent, has side effects that are hard to isolate, or bypasses business rules the UI should enforce.

2. Playwright fixtures next, when setup is test-harness state

Fixtures are the right place for data that behaves like infrastructure for tests. Think of authenticated sessions, seeded account IDs, test users, or shared helpers that encapsulate setup and teardown.

Playwright fixtures are especially useful when the same setup appears across many tests and you want one place to own it. The Playwright docs describe fixtures as a way to share setup and lifecycle across tests, which is exactly why they are useful here.

import { test as base } from '@playwright/test';

export const test = base.extend<{ authToken: string }>({ authToken: async ({ request }, use) => { const res = await request.post(‘/api/login’, { data: { email: ‘qa@example.com’, password: ‘secret’ } }); const { token } = await res.json(); await use(token); } });

Use fixtures for ownership, not for hiding setup. A good fixture is a reusable contract. A bad fixture becomes a second application layer where state appears from nowhere.

3. UI steps last, when the setup itself is part of the test

If the test is meant to validate the onboarding flow, checkout flow, or any other user journey that includes data creation, then UI setup steps should own that data. In that case, the setup is not just scaffolding. It is the behavior under test.

The mistake is using UI setup for everything because it feels end-to-end. That is how suites become slow and brittle. Use the browser to prove browser behavior, not to perform every state transition the backend already handles safely.

A decision tree that actually works

Here is the framework I use when a new test needs data.

Use API setup when all of these are true

  • The API is stable and officially supported.
  • The test does not need to validate the setup flow itself.
  • The data can be created and cleaned up without relying on the browser.
  • You want faster feedback and less flake in CI.

Common examples:

  • Creating a user, workspace, or project before checking UI rendering.
  • Seeding a payment method or feature flag state.
  • Creating backend records that the UI reads but does not create.

Use a Playwright fixture when all of these are true

  • The same setup repeats across multiple tests.
  • The setup belongs to test infrastructure, not product behavior.
  • You want cleanup to be centralized.
  • You need to inject data or session state into many tests.

Common examples:

  • Authenticated browser context.
  • Fresh test tenant per worker.
  • Shared helper that creates a user and returns an ID or token.

Use UI steps when all of these are true

  • The user journey itself matters.
  • The setup exercises validation, permissions, routing, or client-side behavior.
  • There is no stable API for the necessary state.
  • The test is specifically intended to catch regressions in the flow.

Common examples:

  • User registration.
  • Subscription checkout.
  • Multi-step form submission.
  • Any flow where the visible steps are the subject of the assertion.

The practical tradeoffs behind each choice

The debate is not really about elegance. It is about cost and failure modes.

API setup is usually the best default for state creation

API setup tends to win because it is:

  • Faster than browser-driven setup
  • Less sensitive to selectors and rendering changes
  • Easier to make idempotent
  • Easier to reset or isolate per test

But it has tradeoffs.

Failure mode: setup bypasses the real contract

If the API creates state in ways the UI never can, your tests may pass while real users fail. That is not a test data problem, it is a fidelity problem. The fix is not to abandon API setup, but to be explicit about what the test is and is not covering.

Failure mode: hidden business rule drift

If the backend changes a rule and the API test setup still inserts records directly, you may no longer be exercising the same invariants users hit through the interface. For those cases, an API-created record should still look like something a real system could produce.

Fixtures are strongest when the setup is shared and infrastructure-like

Fixtures help keep test files readable, but they can become too powerful. If a fixture creates ten different entities, logs in three users, and seeds half a database, the test file may become short while the system becomes opaque.

The right use of fixtures is narrow ownership. A fixture should answer a question like, “How do I get a logged-in session?” not, “How do I build my entire world?”

If a fixture becomes the place where domain logic lives, it starts competing with the application itself.

A good rule is that fixtures should do boring things consistently. If the setup needs branching business logic, prefer a helper function or an explicit API call inside the test so the behavior stays visible.

UI steps provide fidelity, but they are the most expensive path

UI setup has one advantage that the other two do not: it tells you whether the real interface can create the state.

That matters for flows where the browser and frontend code are part of the risk surface. But UI setup is also the most expensive path in CI, the most sensitive to timing issues, and the hardest to debug when a step fails halfway through.

A common failure mode is using UI setup for preconditions that have nothing to do with what the test validates. If the test is about a dashboard card, there is rarely a good reason to fill out a 12-step onboarding flow first unless onboarding is the thing under test.

What I optimize for in real projects

When I am deciding ownership, I usually optimize in this order:

1. Debuggability

A test should tell me where the state came from. If a failure occurs, I want to know whether the problem is in:

  • the setup path,
  • the browser interaction,
  • or the assertion.

If data is created in a fixture, the fixture should be traceable. If it is created by API, the request should be obvious in the test or a nearby helper. If it is created by UI steps, the flow should be short enough that a human can follow it quickly.

2. Isolation

A test that mutates shared data is a future incident. Shared state is the fastest path to flakiness, especially in parallel CI. In continuous integration, isolated test data is not a luxury, it is what keeps the pipeline trustworthy.

Prefer per-test or per-worker state whenever the product supports it. If the system cannot support clean isolation, that is usually a signal to fix the environment, not to add retries.

3. Speed

UI setup is often the first thing to remove when a suite starts getting slow, because it multiplies cost across every test. API setup is usually the easiest performance win, especially if you can create only the minimal records needed.

4. Fidelity

The closer the setup is to a real user path, the more confidence it can provide, but only if that fidelity matters for the specific test. Do not pay for fidelity you do not need.

A concrete pattern for stable test data

One of the best stable test data patterns is to separate data creation from data verification.

For example, if you need a project in a specific state, create it through the API or fixture, then verify the browser behavior separately.

import { test, expect } from '@playwright/test';

test('project appears in list', async ({ request, page }) => {
  await request.post('/api/projects', {
    data: { name: `proj-${Date.now()}` }
  });

await page.goto(‘/projects’); await expect(page.locator(‘[data-testid=”project-row”]’)).toHaveCount(1); });

The unique name is not the point. The point is that the test does not depend on an old row, a shared fixture, or some invisible cleanup job.

A few things matter here:

  • Make created data easy to identify.
  • Prefer idempotent setup when possible.
  • Clean up explicitly when the environment is long-lived.
  • Use worker-scoped data only when tests are guaranteed not to collide.

How I think about cleanup

Cleanup is part of ownership. If a setup path creates data, it should also define who deletes it or why deletion is unnecessary.

There are three common cleanup models:

Explicit cleanup in the test

Good when the data is small and the ownership is local. This keeps the lifecycle obvious.

Fixture-managed cleanup

Good when setup is reusable and teardown should be hidden from each test case.

Environment reset

Good in ephemeral environments or disposable CI databases. This can simplify tests, but it only works if the environment is actually disposable and the reset is reliable.

A common anti-pattern is assuming cleanup will happen later. In flaky environments, later is often never.

When UI setup is the right answer, even if it is slower

I do not treat UI setup as a smell by default. I treat unnecessary UI setup as a smell.

Use UI steps when:

  • the test is specifically about onboarding, signup, checkout, or another full browser journey,
  • the API does not expose the necessary action,
  • or the browser layer contains meaningful logic, such as conditional rendering, client-side validation, or state derived from local storage.

In those cases, the higher cost is justified because the behavior under test includes the setup path. The test is paying for confidence, not just state creation.

When fixtures are the right answer, even if API setup exists

API setup is not always the cleanest option. If many tests need the same setup, a fixture can reduce repetition and centralize the contract.

For example, a login fixture can encapsulate authentication, token handling, and session reuse. That makes each test shorter and reduces the chance that every file invents its own auth logic.

But I still want the fixture to stay small enough that a reader can understand its effect without tracing half the codebase.

A useful question is: Does this fixture make the test easier to read, or does it hide important state?

If it hides too much, move some of that setup back into an explicit helper or API call.

A simple rubric I use in code review

When I review a test that needs data, I ask these questions:

  1. Could this state be created faster and more reliably outside the browser?
  2. Is the setup path part of the behavior under test?
  3. Will a future engineer know where this data came from?
  4. Does this setup leak across tests or workers?
  5. If it fails in CI, can I debug it from the trace and code alone?

If the answer to 1 is yes and 2 is no, I push toward API setup.

If the answer to 3 is no, I push toward a more explicit helper or a smaller fixture.

If the answer to 4 is uncertain, I look for isolation problems before I look for retries.

If the answer to 5 is no, the setup is probably too clever.

Common mistakes that create flaky tests

Overusing shared fixtures

Shared fixtures that mutate global state are one of the fastest ways to create test pollution. If two tests assume the same record can be edited independently, one of them is wrong.

Using UI for data that should be seeded

This makes suites slow and couples unrelated tests to visual details. A label change, spinner delay, or modal animation should not break a test whose only goal is to check a permissions rule.

Creating data without ownership boundaries

If a test can create data but not clearly destroy it, the environment becomes a junk drawer. That eventually shows up as nondeterministic failures.

Hiding too much behind helpers

Helpers are useful, but over-abstraction can make the setup path impossible to inspect. In test code, explicitness is often more valuable than elegance.

My short rule of thumb

If I need the browser to create the state, I use UI steps.

If I need a reusable test harness object, I use a fixture.

If I just need the state to exist, and I can create it through a supported API, I use API setup.

That is the core of a maintainable Playwright fixtures vs API setup decision. The test should pay for the least expensive path that preserves the behavior it is meant to validate.

Final checklist for choosing ownership

Before you commit to a setup path, ask:

  • Is the setup itself under test?
  • Can I create this state through a stable API?
  • Would a fixture make repeated setup clearer, or just more hidden?
  • Does this state need per-test isolation?
  • Will cleanup be obvious and reliable?
  • If this fails in CI, will the failure point tell me something useful?

If you can answer those honestly, the choice usually becomes obvious.

The best test data ownership model is not the one that looks the most realistic on paper. It is the one that keeps your suite fast enough to run often, isolated enough to trust, and readable enough that the next person can debug it without a tour of the entire system.