Fixtures vs. Factories: Generating Test Data Correctly

1. Two philosophies: fixed fixtures versus generated factories

Anyone building test data for an E2E suite makes an implicit or explicit choice between two philosophies. Static fixtures are fixed data structures, usually stored as a JSON or TypeScript object in the repository, that return exactly the same values on every test run. Factories, on the other hand, are functions that generate test data at runtime, with sensible defaults and the ability to override individual fields on demand. Both approaches solve the same basic problem, namely providing a test object with a defined state, but they make fundamentally different tradeoffs around predictability, flexibility, and maintenance overhead.

The choice between a fixture and a factory is not a matter of taste but an architectural decision that shapes the entire lifetime of the test suite. A team that relies exclusively on fixtures accumulates dozens of nearly identical files over time, one for every variation of a test case. A team that relies exclusively on factories risks unreadable test setups, where the values that actually matter for a given test disappear behind layers of abstraction. The following sections lay out when each approach tends to win, and walk through a practical example for a test customer and a test product.

2. When static fixtures are the better choice

Static fixtures play to their strengths with small, stable datasets that rarely change and whose exact content matters for the test itself. A test that checks whether a specific postal code is formatted correctly, or whether a special character in a last name is escaped correctly, benefits from a fixture with exactly that one peculiar value. Because fixtures do not need to be computed at test time, they are also faster: there is no overhead from random generators, parameter resolution, or object composition.

The biggest advantage, though, is traceability. Anyone opening a fixture file sees immediately and completely which data the test works with, without having to mentally resolve a factory call with several overrides. For onboarding new team members and for code review, this direct link between file and value is a substantial benefit. Fixtures are therefore particularly well suited to reference data, edge cases with exotic characters or formats, and tests that expect an exactly reproducible snapshot.

{
  "customer": {
    "id": "cust_fixture_edge_001",
    "email": "edge.case.customer@example.test",
    "firstname": "Rene",
    "lastname": "O'Connor-Fuentes",
    "address": {
      "street": "Test Street 12",
      "postcode": "80331",
      "city": "Munich",
      "country": "DE"
    },
    "note": "Fixture for escaping and special character tests in the last name, value intentionally kept constant"
  }
}

3. When factories are the better choice

Factories earn their keep the moment a test needs variation that is not practical to represent with a finite number of fixture files. A checkout test that runs through twenty different combinations of payment method, shipping country, and discount code would quickly become unwieldy with twenty separate fixture files. A single factory with parameters for payment method, country, and discount code covers the same range of variation with one function and clearly named calls.

The second, often underestimated advantage concerns parallel test runs. Two tests that use the same static fixture with the same email address collide the moment they run against the same environment at the same time. A factory can generate a unique identifier on every call, for example a random value or a timestamp, and thereby structurally prevents parallel workers from overwriting each other. For edge cases such as locked accounts, expired coupons, or products with zero stock, a parameterized factory is also the only practical way to generate these states deliberately without a separate file per case.

4. Readability versus flexibility

The flexibility of factories comes at a price that only becomes noticeable as the suite grows: readability. A test that calls createCustomer({ isLocked: true }) does not reveal at a glance which of the remaining twenty fields the factory fills in with which default values. Anyone who wants to know whether the address is in Germany or in another country has to open the factory implementation and look up the default values. With a fixture file, this step disappears entirely, because every value is directly visible in the test setup.

This problem gets worse when factories call other factories internally, for example an order factory that combines a customer factory and a product factory under the hood. A test failure in such a setup then requires several layers of debugging before it becomes clear which of the three nested calls produced the unexpected value. The pragmatic rule is to name overrides in the test code itself completely enough that the state relevant to that particular test is readable directly from the call, instead of relying on implicit defaults scattered elsewhere in the project.

5. Avoiding factory overengineering

Factories invite adding more and more flexibility until the abstraction itself becomes a maintenance problem. A typical warning sign is the builder chain, where a factory is configured through .withAddress().withLockedAccount().withGroup(3).build(). Every additional with method increases the surface area of the factory itself and demands its own tests, its own documentation, and its own maintenance, even though in practice only two or three combinations end up actually being used.

Trait or plugin systems that try to anticipate every conceivable future combination are similarly risky. The result is often a factory with fifty configuration options, of which the test suite actually uses only five. The YAGNI principle applies to test data just as much as to production code: a factory should start with the overrides that currently existing tests need, and grow only when a new test has a real, concrete need. A simple function with a flat overrides object is almost always more maintainable than a generic, configurable builder hierarchy that nobody fully understands anymore.

// ANTI-PATTERN: an overengineered builder chain for customer test data.
// Twelve "with" methods exist, but most tests only ever use two of them.
class CustomerBuilder {
  private data: Record<string, unknown> = {
    email: 'default@example.test',
    isLocked: false,
    groupId: 1,
  };

  withAddress(address: unknown): this { this.data.address = address; return this; }
  withLockedAccount(): this { this.data.isLocked = true; return this; }
  withGroup(id: number): this { this.data.groupId = id; return this; }
  withNewsletterOptIn(): this { this.data.newsletter = true; return this; }
  withLoyaltyTier(tier: string): this { this.data.loyaltyTier = tier; return this; }
  // ... seven more "with" methods, each used in exactly one test

  build(): Record<string, unknown> { return this.data; }
}

// Reading this call requires opening the builder class to know what
// "withGroup(3)" actually sets on the resulting customer object.
const customer = new CustomerBuilder()
  .withGroup(3)
  .withLockedAccount()
  .build();

// BETTER: a flat factory function with named overrides, see section 6 below.

6. Practical example: a factory for the test customer

A good customer factory starts with sensible defaults for a typical, valid customer and allows targeted overrides for the fields a specific test actually needs to vary. It is important that the factory generates a unique email address, for example through a random data library like Faker, so that parallel test runs do not block each other. Overrides should be passed as a flat, optional object, not as nested configuration, so the call stays readable in the test itself.

The example below shows a TypeScript factory that creates a test customer through the application API. The defaults cover the most common case, an active, unlocked customer with a valid address. For edge cases like a locked account, a single override field is enough, without a test having to know or repeat the remaining twenty fields.

// factories/customer.factory.ts
import { faker } from '@faker-js/faker';
import { apiClient } from '../support/api-client';

interface CustomerOverrides {
  email?: string;
  isLocked?: boolean;
  groupId?: number;
  country?: string;
}

/**
 * Creates a customer via the application API with sensible defaults.
 * Overrides let individual tests target specific edge cases without
 * having to repeat every unrelated field.
 */
export async function createCustomer(overrides: CustomerOverrides = {}) {
  const payload = {
    // Unique email per call keeps parallel test workers collision free
    email: overrides.email ?? `customer.${faker.string.uuid()}@example.test`,
    firstname: faker.person.firstName(),
    lastname: faker.person.lastName(),
    groupId: overrides.groupId ?? 1,
    isLocked: overrides.isLocked ?? false,
    country: overrides.country ?? 'DE',
  };

  const response = await apiClient.post('/customers', payload);
  return response.data; // includes generated id, used later for cleanup
}

7. Practical example: a test product fixture with a variant factory

For a test product, the reverse approach is often the right fit: a static fixture for the standard product used unchanged by most tests, plus a supporting factory for the cases where a test needs a specific variant, for example different stock levels, prices, or special characters in the product name. The standard product rarely changes, so for this one object the determinism of a fixture file is worth more than the flexibility of a factory.

For stock tests, pricing tests, or localization tests, the static fixture alone is not enough, because each of these tests needs a different state of the product. A lean product factory that builds on the same base values as the fixture, but allows targeted overrides for stock, price, or name, covers these cases without a separate file per combination. The two approaches are not mutually exclusive, they complement each other for the same product entity.

// fixtures/test-product.fixture.ts
// Stable base product, used unmodified by the majority of tests.
export const TEST_PRODUCT_FIXTURE = {
  sku: 'TEST-PRODUCT-BASE',
  name: 'Fixture Test Product',
  price: 49.90,
  qty: 100,
  status: 1,
} as const;

// factories/product.factory.ts
// Builds edge case variants on top of the same stable base fixture.
interface ProductVariantOverrides {
  qty?: number;
  price?: number;
  name?: string;
}

export function createProductVariant(overrides: ProductVariantOverrides = {}) {
  return {
    ...TEST_PRODUCT_FIXTURE,
    // Unique SKU per call avoids collisions between parallel test runs
    sku: `TEST-PRODUCT-${Date.now()}-${Math.floor(Math.random() * 1000)}`,
    ...overrides,
  };
}

// Edge cases built on the same stable base, no separate file per case
const outOfStock = createProductVariant({ qty: 0 });
const heavilyDiscounted = createProductVariant({ price: 0.01 });

8. The hybrid approach: 80 percent fixtures, 20 percent factories

In practice, a combination almost always works better than a dogmatic commitment to one of the two approaches. The rule of thumb: fixtures for the part of the test data that stays stable across the whole suite and rarely needs variation, factories for the part that requires a different state from test to test. In practice this ratio often lands close to eighty to twenty, which is where the name of the pattern comes from.

Concretely that means: a reference catalog with standard products, fixed configuration values, and edge cases with exotic characters stay fixtures. Core entities that must vary differently for every test, for example customers with different account statuses or orders with different line items, get generated through factories. This hybrid pattern keeps the number of fixture files small and manageable, while factories are used only where their flexibility is actually needed, instead of reaching for them reflexively for every test data situation.

// e2e/checkout.spec.ts
// Hybrid usage: fixture for the stable product, factory for the variable customer state
import { test, expect } from '@playwright/test';
import { TEST_PRODUCT_FIXTURE } from '../fixtures/test-product.fixture';
import { createCustomer } from '../factories/customer.factory';

test('locked customer cannot complete checkout', async ({ page }) => {
  // Stable reference product: the fixture is enough, no factory needed
  const product = TEST_PRODUCT_FIXTURE;

  // Variable customer state: factory generates a unique, locked account
  const customer = await createCustomer({ isLocked: true });

  await page.goto(`/product/${product.sku}`);
  await page.getByRole('button', { name: 'Add to cart' }).click();
  await page.goto('/checkout');
  await page.getByLabel('Email').fill(customer.email);

  await expect(page.getByText('Account is locked')).toBeVisible();
});

9. Fixtures and factories compared

Both approaches have a legitimate place in an E2E suite, but the choice has direct consequences for readability, setup speed, and parallelizability. The following overview compares both strategies along the most important decision dimensions.

The table shows why a dogmatic commitment to a single approach is rarely the best solution: fixtures win on readability and speed, factories win on edge case coverage and parallel safety. Anyone who deliberately assigns these strengths per test data type, instead of using one approach out of habit for everything, reduces both the number of fixture files and the complexity of the factories at the same time.

10. Summary

The choice between fixtures and factories is not a matter of style, it is an architectural decision with direct effects on readability, speed, and parallelizability of the test suite. Static fixtures deliver maximum traceability and speed for stable, rarely changing data, but drift into an unmanageable pile of nearly identical files if they remain the only tool. Parameterized factories cover variation and edge cases elegantly and structurally protect parallel test runs from collisions, but lose readability the moment their defaults and overrides are no longer obvious at a glance.

The decisive lever is consistently avoiding overengineering in factories: a flat function with clearly named overrides beats a deeply nested builder hierarchy almost every time. The hybrid model, stable reference data as fixtures and variable core entities as factories, covers most requirements in practice without forcing a team to commit to a single approach. Anyone who makes this split deliberately, by purpose rather than by habit, ends up with a suite that stays both readable and flexible.

11. FAQ: Fixtures vs. Factories