Data Strategy

Tier 2 — Domain-specific static data (test-data/static/{area}/)

Create a new .ts file here when you have a curated set of invalid or boundary values that are specific to the application's validation rules (invalid email formats, weak-password policy violations, forbidden enum values, locale strings, etc.).

Two canonical shapes — pick whichever fits the call site:

Shape A — per-field invalid-value arrays (the shape used by the scaffold's existing test-data/static/app/invalidCredentials.ts):

export const INVALID_EMAILS = [
    '',
    'plaintext',
    'missing-at-sign.com',
    'missing@domain',
    '@missing-local.com',
    'double@@at.com',
] as const;

export const INVALID_PASSWORDS = ['', '123', 'short', 'NoNumber!'] as const;

Use Shape A when each invalid value targets one field at a time (classic per-field negative loop).

Shape B — test-case objects with descriptions for parametrised tests that combine multiple fields:

export const INVALID_LOGIN_ATTEMPTS = [
    {
        description: 'valid email with wrong password',
        email: 'test.user@example.com',
        password: 'WrongPassword123!',
    },
    {
        description: 'unknown email with any password',
        email: 'nobody@example.com',
        password: 'AnyPassword123!',
    },
] as const;

Use Shape B when each row represents a scenario with multiple fields that must be tested together.

Always .ts with as const. Never .json. .ts gives type safety, undefined/NaN support, narrow literal autocomplete, JSDoc comments explaining rationale, and compiler-assisted refactors — all lost with JSON.

Tier 3 — Field-specific boundary values

These stay inline in the spec file. Do not create a static file for a single out-of-range set.

const outOfRangeRatings = [-1, 0, 0.99, 5.01, 6, 1000];

Promote to Tier 2 only if the same boundary set is reused across 2+ fields or spec files.

Phase 4: Consume the data in tests

Factory (happy path or setup):

import {
    generateUser,
    generateLoginCredentials,
} from '../../../test-data/factories/app/user.factory';

const user = generateUser();
const creds = generateLoginCredentials();

const adminUser = generateUser({ email: 'admin@company.com' });
const customCreds = generateLoginCredentials({
    password: 'SpecificPassword123!',
});

Universal invalid arrays (Tier 1):

import { INVALID_STRING_VALUES } from '../../../test-data/static/util/invalid-values';

for (const invalidValue of INVALID_STRING_VALUES) {
    test(
        `should return 400 when name is ${JSON.stringify(invalidValue)}`,
        { tag: '@api' },
        async ({ apiRequest }) => {
            // ...
        }
    );
}

Domain-specific static data (Tier 2) and field-specific boundary (Tier 3) — full snippets in references/examples.md. Same for...of pattern as Tier 1 above; Tier 2 imports a named as const export from test-data/static/{area}/, Tier 3 declares the array inline.

Phase 5: Editing existing static data

When you need to update a value in test-data/static/, the change can break existing test assertions and expectations that rely on the old value. Always search for all consumers before editing.

Read the refactor-values skill (.claude/skills/refactor-values/SKILL.md) before modifying any existing static-data file or enum value. It owns the impact-analysis + cascading-update workflow.

No Magic Numbers

Do not hardcode timeouts, retry counts, or other tuning numbers inline. The preferred path is web-first assertions — Playwright waits for the condition automatically:

// FORBIDDEN -- hard wait masks real timing issues
await page.waitForTimeout(5000);

// CORRECT -- web-first assertion, no magic number needed
await expect(appPage.successMessage).toBeVisible();

When a numeric tuning value is genuinely unavoidable:

• Test-suite tuning (default action timeout, expect timeout, retries, workers) → playwright.config.ts (see the config skill).
• Domain-level limits (max retries for a custom helper, page-size constants) → an enum in enums/{area}/* (see the enums skill).
• Per-assertion override (one assertion that legitimately needs more time) → pass inline on the assertion: await expect(locator).toBeVisible({ timeout: 10000 }). Justify why in a short comment.

See Also

• api-testing skill — Phase 6 three-tier consumer pattern, per-field for...of loops, negative-validation coverage matrix.
• refactor-values skill — impact analysis and cascading update workflow for enum values and static data changes.
• type-safety skill — Zod 4 validator reference and z.strictObject() patterns used in factory validation.
• enums skill — canonical home for app-defined strings (error messages, labels, route paths).
• config skill — where timeouts / retries / workers belong (playwright.config.ts), not test-data/.
• debugging skill — when a factory output fails Schema.parse(...) or a data-driven loop fails one row out of many, classify and investigate before mutating the factory.
• references/examples.md — three worked walkthroughs (new factory, domain-specific invalid set, full negative-API coverage combining factory + universal + boundary) plus Tier 2 + Tier 3 consumption snippets.
• references/troubleshooting.md — common data-strategy pitfalls (parallel collisions, factory schema parse failure, inline invalid arrays, Faker-generated app strings, single-string JSON, edits to existing static data, magic-number timeouts).