What are the risks of shared authentication state?

The Answer

Sharing auth state between tests creates hidden dependencies. If one test modifies user data (profile, settings, permissions), subsequent tests may fail due to unexpected state changes.

Deep Dive Explanation

The safest approach is to never modify persistent state in tests that share auth. For tests that must modify data, use API calls to set up AND tear down that data, or use unique data per test run (e.g., generate a unique email for each test user).

example.spec.ts

// ❌ RISKY: Shared auth state with side effects
test('update profile', async ({ page }) => {
  // Uses shared auth.json
  await page.goto('/profile');
  await page.getByLabel('Name').fill('Changed Name'); // Modifies shared state!
  await page.getByRole('button', { name: 'Save' }).click();
});

test('check profile name', async ({ page }) => {
  // May fail if 'update profile' ran first and changed the name
  await expect(page.getByLabel('Name')).toHaveValue('Original Name'); // ❌
});

// ✅ SAFER: Use API to reset state before/after
test.afterEach(async ({ request }) => {
  await request.put('/api/profile', { data: { name: 'Original Name' } });
});