Test Fixture vs Factory

Test Dataintermediate

// Definition

Two ways to produce test data. A fixture is a fixed, predefined dataset loaded as-is (the same "User 1" every time) — predictable but rigid. A factory generates objects on demand with sensible defaults you override per test (`buildUser({ role: 'admin' })`) — flexible and DRY. Fixtures suit a stable shared baseline; factories suit tests that each need a slightly different variant.

// Why it matters

Choosing wrong makes a suite either brittle or unreadable. All-fixtures means every test shares state and a schema change breaks dozens of files; all-inline-data means tests are noisy and duplicated. QA cares because the fixture/factory balance is a major driver of how maintainable a test suite is as it grows — it's an architecture decision, not a detail.

// How to test

// Fixture: fixed, shared, predictable
cy.fixture('users/admin.json').as('admin') // same data every run

// Factory: generated, overridable per test
const buildUser = (overrides = {}) => ({
  name: 'Test User', role: 'viewer', active: true, ...overrides,
})
const adminUser = buildUser({ role: 'admin' }) // only the difference is stated
cy.request('POST', '/api/users', adminUser)

// Common mistakes

  • All fixtures: a schema change breaks every fixture file at once
  • All inline data: duplicated, noisy tests where the relevant difference is buried
  • Factories with no sensible defaults (every call must specify everything)

// Related terms