Handling Shared Resources and Test Data

Parallel execution puts pressure on how you design shared resources like users, test data and environments. If multiple tests compete for the same state, you can get intermittent failures that are hard to reproduce.

Designing Parallel-Safe Test Data #

To keep tests independent, you need data strategies that avoid collisions. Common patterns include unique identifiers per test, per-worker data partitions and ephemeral test fixtures that clean up after themselves.

// example of generating unique data per test
import { test, expect } from '@playwright/test';

-test('creates a unique user per test', async ({ page }, testInfo) => {
+test('creates a unique user per test', async ({ page }, testInfo) => {
  const uniqueEmail = `user+${testInfo.testId}@example.com`;

  await page.goto('https://demo.myshop.com/register');
  await page.getByLabel('Email').fill(uniqueEmail);
  await page.getByLabel('Password').fill('SuperSecret123');
  await page.getByRole('button', { name: 'Sign up' }).click();

  await expect(page.getByText('Welcome')).toBeVisible();
});

For environments, consider whether each worker needs its own namespace (such as a tenant or database schema) or whether read-only data can be shared safely.

Common Mistakes #

Mistake 1 — Reusing the same mutable user for many tests #

This leads to state leaks.

❌ Wrong: Having all tests log in as qa-user@example.com and modify their profile and orders.

✅ Correct: Use unique or partitioned users so tests cannot interfere with each other.

Mistake 2 — Doing all setup through the UI in parallel #

This is slow and fragile.

❌ Wrong: Creating complex data only via web flows in every test.

✅ Correct: Use backend APIs or fixtures to prepare data more efficiently.