Test Data

Static vs Dynamic Data

Static JSON in tests/fixtures/ works for read-only reference data — country lists, product catalogs. Mutable flows need unique emails/IDs per test via factories or timestamps.

Import JSON directly in TypeScript or load with fs.readFileSync. For API seeding, create data in beforeEach and delete in afterEach.

import users from '../fixtures/users.json';
import { faker } from '@faker-js/faker';

test('register', async ({ page }) => {
  const email = faker.internet.email();
  await page.getByLabel('Email').fill(email);
  // ...
});

Faker generates unique values — safe for parallel tests.

Data Strategies

// Static reference
import catalog from './fixtures/catalog.json';

// Factory function
function createUser(overrides = {}) {
  return { email: faker.internet.email(), ...overrides };
}

• Static JSON for immutable reference data.
• Factories for entities created per test.
• API seeding faster than UI creation for prerequisites.
• Never depend on hard-coded row id '1' in shared DB.

Test Data Patterns

Choose the right data approach.

Data-Driven Tests

const cases = [
  { role: 'admin', path: '/admin' },
  { role: 'user', path: '/dashboard' },
];
for (const c of cases) {
  test(`redirects ${c.role}`, async ({ page }) => {
    // login as c.role, expect c.path
  });
}

Unique Identifiers in Parallel Runs

Generate unique emails with user-${Date.now()}@test.com or crypto.randomUUID() so parallel tests creating accounts never violate unique constraints in shared databases.

Common Mistakes

• Same email used across parallel tests causing unique constraint errors.
• Tests depending on execution order for data existence.
• Production database used for test data creation.
• Huge fixture files copied into every test unnecessarily.

Key Takeaways

• Isolate data per test for parallel safety.
• Combine static fixtures with dynamic factories.
• Seed via API when UI setup is slow.
• Data-driven tests reduce duplication for role/variant matrices.