Write a Playwright test that finds a seeded drill, saves practice completion, reloads, and proves the state persisted in an isolated test environment.

• Never point the test at production or a shared developer database.
• Seed through a supported test API or fixture, not direct production-table writes.
• Give every worker unique user and drill identifiers.
• Authenticate through a fixture or stored state without testing unrelated registration screens.
• Use role, label, and exact user-visible text locators.
• Use Playwright web-first assertions; fixed sleeps are forbidden.
• Verify persistence after a reload or through the isolated API.
• Cleanup must run when the test fails.

1. Build a worker-scoped fixture that creates a unique candidate and drill in an isolated test database and registers cleanup.
2. Authenticate the page directly through the supported test login helper; keep this test focused on practice progress.
3. Navigate to /drills, locate search by accessible name, and enter the exact seeded title.
4. Scope the link lookup to the matching result so unrelated drills cannot satisfy it.
5. Open the drill, mark it complete, and use a web-first assertion for the saved state.
6. Reload and assert the durable state again, proving this is not only optimistic client state.
7. Let the fixture delete only its own records in teardown. Capture a trace on retry rather than adding sleeps to hide races.

import { expect, test as base } from "@playwright/test";

type PracticeFixture = {
  candidate: { id: string; email: string };
  drill: { id: string; title: string; slug: string };
};

const test = base.extend<{ practiceFixture: PracticeFixture }>({
  practiceFixture: async ({ request }, use, testInfo) => {
    const suffix = `${testInfo.workerIndex}-${crypto.randomUUID()}`;
    const response = await request.post("/api/test-fixtures/practice", {
      data: { suffix, topic: "SQL" },
    });
    expect(response.ok()).toBeTruthy();
    const fixture = await response.json() as PracticeFixture;

    try {
      await use(fixture);
    } finally {
      await request.delete(`/api/test-fixtures/practice/${fixture.candidate.id}`);
    }
  },
});

test("candidate completes a filtered drill", async ({
  page,
  request,
  practiceFixture,
}) => {
  await authenticateTestCandidate(request, page, practiceFixture.candidate);

  await page.goto("/drills");
  await page.getByRole("textbox", { name: "Search drills" })
    .fill(practiceFixture.drill.title);

  const result = page.getByRole("article", {
    name: practiceFixture.drill.title,
  });
  await expect(result).toBeVisible();
  await result.getByRole("link", { name: "Practice drill" }).click();

  await expect(page).toHaveURL(new RegExp(`/drills/${practiceFixture.drill.slug}`));
  await page.getByRole("button", { name: "Mark complete" }).click();
  await expect(page.getByText("Practice saved")).toBeVisible();

  await page.reload();
  await expect(page.getByRole("button", { name: "Completed" })).toBeVisible();
});

The fixture endpoint exists only in the test host and uses an isolated database. In a real suite, authentication and cleanup helpers would be reusable fixtures rather than application routes exposed in production.

This test crosses browser, routing, authentication, API, and persistence boundaries, so it is slower and more failure-prone than a component or API test. That cost is justified for one critical path, not every validation branch. API-based setup avoids unrelated UI work but requires a carefully restricted test fixture surface. Per-worker data enables parallelism at the cost of more setup and cleanup, while traces and screenshots should diagnose retries rather than normalize flaky behavior.

• Search returns several similar titles, so the locator must scope to the exact seeded result.
• The save response is slow but eventually succeeds.
• Authentication expires before the mutation.
• Optimistic UI says complete while persistence fails.
• Reload occurs before server state becomes readable.
• A test fails before normal teardown.
• Parallel workers accidentally reuse the same identity or slug.
• Cleanup returns not found because a previous retry already removed the fixture.

• Assert that the fixture endpoint succeeded before using its data.
• Run two workers and prove generated identifiers do not collide.
• Verify the result locator cannot match a neighboring drill.
• Delay the save response and rely on Playwright auto-waiting rather than waitForTimeout.
• Reload before the final assertion so client-only state cannot pass.
• Force a mid-test failure and confirm teardown still removes the fixture.
• Record a trace on retry and keep production base URLs blocked by configuration.
• Ensure no test writes to the real content or user database.

• The test points at a shared or production database.
• It clicks through registration and content creation even though those are separate concerns.
• Fixed sleeps hide an unresolved race and slow every run.
• CSS selectors or position-based locators break after harmless UI changes.
• The assertion stops at an optimistic success message and never proves persistence.
• Shared fixture identities collide under parallel execution.
• Cleanup runs only after success, leaving polluted test data when an assertion fails.
• One end-to-end test tries to cover every validation and failure branch.