The most common reason an end-to-end suite becomes untrustworthy isn’t timing; it’s shared state. Test 12 passes alone and fails in the full run because test 7 renamed the group it uses. Or a test passes only on Mondays because the seed data has a “this week” expense. Isolation is the cure, and Playwright gives you most of it for free.
\nEach test receives its own browser context: an incognito-like profile with its own cookies, localStorage, sessionStorage and cache. Opening a context is cheap (milliseconds, not a new browser), so Playwright creates a new one per test. That’s why you can run with fullyParallel: true across several workers: two tests can’t see each other’s logins or saved drafts.
The browser side is isolated. Your backend is not. If two tests edit the same group on the same server, they collide. The rest of this lesson is about isolating data.
\nYou’ve been using fixtures already: page in async ({ page }) => … is one. Playwright also ships context, browser, browserName and request (an HTTP client that shares baseURL). You define your own with test.extend:
import { test as base, expect } from '@playwright/test';\n\ntype Group = { id: string; name: string };\n\nexport const test = base.extend<{ group: Group }>({\n group: async ({ request }, use) => {\n // Setup: create a fresh group through the API\n const response = await request.post('/api/groups', {\n data: { name: `Trip ${crypto.randomUUID().slice(0, 8)}`, members: ['Ana', 'Ben'] },\n });\n expect(response.ok()).toBeTruthy();\n const group: Group = await response.json();\n\n await use(group); // the test runs here\n\n // Teardown: runs after the test, pass or fail\n await request.delete(`/api/groups/${group.id}`);\n },\n});\n\nexport { expect };import { test, expect } from './fixtures';\n\ntest('settling up clears every balance', async ({ page, group }) => {\n await page.goto(`/groups/${group.id}`);\n // …add an expense, click Settle up…\n await expect(page.getByRole('status')).toHaveText('Everyone is settled up');\n});Three properties make this better than a beforeEach:
group in their parameters create one. Tests that don’t need it pay nothing.await use(...), so cleanup can’t drift out of sync with setup.group fixture can depend on request; an expense fixture could depend on group. Playwright resolves the order.Creating data through the API rather than clicking through the UI keeps each test focused on one flow and saves seconds per test. One test clicks through “create a group”; the other fifty get a group from the fixture.
\n\nIf Splitwise-lite requires login, clicking through the form in every test wastes time and hammers your auth server. Playwright’s pattern is a setup project: one test logs in and saves the browser’s storage state to a file, and the real projects declare a dependency on it and start already logged in:
\n// …inside defineConfig\nprojects: [\n { name: 'setup', testMatch: /.*\\.setup\\.ts/ },\n {\n name: 'chromium',\n use: { ...devices['Desktop Chrome'], storageState: 'playwright/.auth/user.json' },\n dependencies: ['setup'],\n },\n],The setup test ends with await page.context().storageState({ path: 'playwright/.auth/user.json' }). Add playwright/.auth to .gitignore: it contains real session cookies.
Some states are hard to produce with a real backend: a 500 on save, a slow response, an empty group from a legacy account. page.route intercepts requests from the page and lets you answer them:
test('explains a failed save', async ({ page, group }) => {\n await page.route('**/api/expenses', (route) =>\n route.fulfill({ status: 500, json: { error: 'Database unavailable' } }),\n );\n\n await page.goto(`/groups/${group.id}`);\n await page.getByLabel('Description').fill('Dinner');\n await page.getByLabel('Amount').fill('30');\n await page.getByRole('button', { name: 'Add expense' }).click();\n\n await expect(page.getByRole('alert')).toHaveText('Could not save the expense. Try again.');\n});Use routing for the rare and the broken. If you find yourself routing every request, you’ve rebuilt a component test in a slower tool; let the happy paths hit the real backend, because that integration is what end-to-end tests are for.
\n\nIsolation also makes failures cheaper to debug. When a test fails, you can rerun that single test with npx playwright test -g "settling up" and get the same result, because nothing it depends on lives outside it. With hidden dependencies, the single rerun passes and the full run fails, and you’re left bisecting the suite to find which neighbour broke it.
In the exercise you complete a fixture that creates and deletes a group. Next lesson: what to do when a test fails anyway.
\n","toc":[{"id":"sec-1","text":"Fresh context for every test","level":2},{"id":"sec-2","text":"Fixtures: setup and cleanup in one place","level":2},{"id":"sec-3","text":"Logging in once","level":2},{"id":"sec-4","text":"Routing: controlling what the server says","level":2}],"takeaways":["Every Playwright test gets a fresh browser context (its own cookies, storage and cache), so tests can run in parallel and in any order.","A fixture created withtest.extend sets something up, hands it to the test with use(), and tears it down afterwards, only for tests that ask for it.","Each test should create the data it needs (ideally through the API) instead of depending on shared seed data or on another test having run first.","Log in once in a setup project, save the storage state, and reuse it, rather than clicking through the login form in every test.","Use page.route to simulate rare server responses, and the real backend for the happy paths."],"further":[{"title":"Playwright — Fixtures","url":"https://playwright.dev/docs/test-fixtures"},{"title":"Playwright — Isolation","url":"https://playwright.dev/docs/browser-contexts"},{"title":"Playwright — Authentication","url":"https://playwright.dev/docs/auth"},{"title":"Playwright — Mock APIs","url":"https://playwright.dev/docs/mock"}],"quiz":[{"q":"Test A creates a group named “Lisbon trip”; test B opens “Lisbon trip” and checks its balances. B passes locally and fails in CI. What’s the root problem?
","options":[{"text":"CI machines are slower, so B needs a longer timeout.","why":"Speed isn’t the issue; B depends on data that only exists if A ran first, on the same server, before it."},{"text":"B depends on A’s data. With parallel workers or a different order, the group doesn’t exist yet when B runs.","why":"Correct. Each test should create its own group, for example through a fixture that calls the API and cleans up after."},{"text":"B should usetest.describe.serial so it always runs after A.","why":"Serial mode makes the dependency official and the suite slower; one failure in A then skips everything after it. Remove the dependency instead."}],"answer":1},{"q":"In a fixture, what does the code after await use(group) do?
use; the line after it waits until the test is done."},{"text":"Nothing; code after use is never reached.","why":"use resolves when the test finishes, so the code after it runs, which is how fixtures clean up."},{"text":"It runs after the test finishes, even if the test failed, which makes it the place for cleanup.","why":"Correct. Setup, use(value), teardown: one function owns the whole lifecycle of the resource."}],"answer":2},{"q":"What is the best use of page.route in an end-to-end suite?
Finish this Playwright fixture so every test that asks for a group gets a fresh one created through the API, and the group is deleted after the test, pass or fail. Then finish the test so it receives the fixture and uses a web-first assertion.
test object that returns a new, extended test.","The fixture needs the built-in HTTP client fixture, the one the body calls .post on.","Hand the value to the test with the second parameter of the fixture function; afterwards, clean up with the HTTP method that removes a resource. The test lists the fixture by name in its parameters, and asserts with Playwright’s retrying expect."],"explanation":"base.extend<{ group: Group }>({...}) returns a new test that knows about the group fixture. The fixture asks for the built-in request fixture, creates a group with a unique name, and passes it to the test with await use(group). Everything after use runs when the test finishes, whatever the outcome, so request.delete(...) cleans up even after a failure. The test opts in by destructuring group next to page; tests that don’t mention it never create one. Finally, await expect(locator).toHaveText(...) retries until the status appears, so the test doesn’t race the page load.