Fixtures vs Factories: Test Data Strategies

Static test fixtures become stale and hard to maintain. Tests that share fixture objects fail when one test mutates the shared data. Large fixture files obscure what a test actually cares about.

Use factory functions with sensible defaults that tests can override minimally.

// Factory pattern with partial overrides
function createUser(overrides: Partial<User> = {}): User {
  return {
    id: 'usr_test_' + Math.random().toString(36).slice(2),
    name: 'Test User',
    email: 'test@example.com',
    role: 'user',
    createdAt: new Date('2024-01-01'),
    ...overrides,
  };
}

// Test only specifies what matters
test('admin can delete users', () => {
  const admin = createUser({ role: 'admin' });
  const target = createUser();
  expect(canDelete(admin, target)).toBe(true);
});

// For DB-backed tests, use factory-boy or similar
import { factory } from 'factory-girl';
factory.define('user', UserModel, {
  name: factory.sequence('user.name', (n: number) => `User ${n}`),
  email: factory.sequence('user.email', (n: number) => `user${n}@test.com`),
});

const user = await factory.create('user', { role: 'admin' });

Factories express test intent (only the fields that matter), produce isolated data per test (no shared references), and are easy to maintain when the model changes.