Cypress Test Data Strategies

Static vs. Dynamic Test Data

Static fixtures are simple and predictable but can become stale or collide when multiple tests need slightly different variations of similar data. Dynamically generated data, built at runtime with a factory function, trades a little predictability for flexibility and avoids hardcoded collisions like duplicate emails across parallel test runs.

// Dynamic factory, avoids collisions across parallel runs
const createUser = (overrides = {}) => ({
  email: `user-${Date.now()}@example.com`,
  password: 'SecurePass123!',
  ...overrides,
});

cy.get('[data-cy="email"]').type(createUser().email);

Using Date.now() (or a UUID) in generated data avoids collisions when many tests run in parallel against a shared environment.

Common Test Data Sources

cy.fixture('data.json')          // static file
createUser({ role: 'admin' })    // dynamic factory function
cy.request('POST', '/test/seed') // backend seeding via API
cy.task('db:seed', { ... })      // backend seeding via Node task

• Static fixtures are best for stable, rarely-changing reference data.
• Factory functions are best for data that needs slight variation per test or run.
• API-based seeding sets up real backend state for tests that depend on it existing.
• cy.task() runs Node.js code directly, useful for direct database access during seeding.

Test Data Strategy Cheat Sheet

Choosing the right test data approach for a given scenario.

Seeding Backend State via API

When a test needs real backend state to exist, an account, an order, a specific permission, calling a dedicated setup API endpoint directly (rather than clicking through the UI to create it) is significantly faster and decouples the test's setup from unrelated UI flows.

beforeEach(() => {
  cy.request('POST', '/test/seed/user', {
    email: 'test-user@example.com',
    role: 'admin',
  }).then((response) => {
    cy.wrap(response.body.userId).as('userId');
  });
});

This test-only seeding endpoint should be disabled outside test/staging environments for safety.

Using cy.task() for Direct Data Access

cy.task() runs arbitrary Node.js code in Cypress's backend process, giving tests access to things a browser cannot do directly, like querying a database or reading a file on disk, useful when no convenient API endpoint exists for seeding or verification.

// cypress.config.js
export default defineConfig({
  e2e: {
    setupNodeEvents(on) {
      on('task', {
        'db:seed'(data) {
          return seedDatabase(data); // your own Node.js logic
        },
      });
    },
  },
});

// in a spec file
cy.task('db:seed', { users: 3 });

Common Mistakes

• Hardcoding unique-looking values (like a specific email) that eventually collide across parallel or repeated test runs.
• Setting up backend state by clicking through the UI when a direct API call would be far faster and more reliable.
• Leaving test-only seeding endpoints reachable in production environments.
• Mixing static fixtures and dynamic factories inconsistently for the same kind of data across a suite.

Key Takeaways

• Static fixtures suit stable data; dynamic factories suit data needing per-run uniqueness.
• API-based seeding sets up real backend state faster and more reliably than UI-driven setup.
• cy.task() gives tests access to Node.js-level operations like direct database seeding.
• Always guard test-only setup/reset endpoints so they cannot run in production.