Strategie danych testowych i fixtures

Twój zestaw testów używa 500-liniowego pliku seed skopiowanego z produkcji trzy lata temu. Połowa testów zależy od istnienia “John Doe” z emailem “john@test.com” i user ID 1. Gdy ktoś doda unique constraint na email, czterdzieści testów się psuje. Gdy schemat się zmienia, plik seed wymaga ręcznej aktualizacji zajmującej pół dnia. Dane testowe są fundamentem Twojej infrastruktury testowej — a większość zespołów traktuje je jako rzecz drugorzędną.

Czego się nauczysz

• Implementację wzorca factory generującą spójne, realistyczne dane testowe na żądanie
• Strategie zarządzania fixtures dla różnych warstw testowych (unit, integracyjne, E2E)
• Generowanie danych zgodne z prywatnością naśladujące wzorce produkcyjne bez prawdziwych PII
• Workflow seedowania bazy danych dla testów integracyjnych i E2E
• Prompty do generowania fabryk danych testowych specyficznych dla domeny

Wzorzec factory

Fabryki zastępują zahardkodowane dane testowe konfigurowalnymi generatorami produkującymi świeże, unikalne dane dla każdego testu.

Cursor

@src/lib/db/schema.ts
Generate test data factories for every entity in our database schema:

For each table, create a factory at /tests/factories/{entity}.factory.ts that:
1. Uses @faker-js/faker for realistic data generation
2. Has build() - returns a plain object (for unit tests, no DB)
3. Has create(db) - inserts into the database and returns the record
4. Has buildList(count) - generates an array of objects
5. Has createList(db, count) - inserts multiple records
6. Supports overrides: build({ email: 'specific@test.com' })
7. Supports traits: build('admin'), build('suspended')
8. Handles foreign keys: OrderFactory.create() auto-creates a User if needed
9. Generates UNIQUE values (no collisions even with 1000 records)

Create a factory index at /tests/factories/index.ts that exports all factories.
Follow our Drizzle ORM patterns for database insertions.

Claude Code

claude "Read our database schema at /src/lib/db/schema.ts and generate
test data factories for every entity.

Save to /tests/factories/ with one file per entity.
Each factory must:
- Use faker.js for data generation
- Support build() and create() patterns
- Handle foreign key relationships automatically
- Generate unique values per invocation
- Support overrides and traits

After creating factories, verify they work by:
1. Building 100 of each entity (no collisions)
2. Creating 10 of each in the test database (relationships resolve)
3. Running existing tests to verify compatibility"

Codex

Generate test data factories for all database entities:
1. Read the database schema
2. Create factory files with build/create patterns
3. Handle entity relationships and foreign keys
4. Verify factories produce valid data
5. Create a PR with the factory infrastructure

Wskazówka

Prompt do skopiowania — fabryki specyficzne dla domeny:

Create test data factories for our e-commerce domain:

UserFactory:
- Traits: 'admin', 'premium', 'suspended', 'new' (created today)
- Generates realistic names, emails, and addresses
- hashedPassword defaults to bcrypt hash of "Test1234!"

ProductFactory:
- Traits: 'outOfStock' (stock=0), 'onSale' (discount > 0), 'digital' (no shipping)
- Price between $1-999 (realistic distribution, not random)
- SKU format: "PRD-XXXXX" (unique)
- Category from our actual category list

OrderFactory:
- Auto-creates a User and 1-5 Products when needed
- Traits: 'pending', 'shipped', 'delivered', 'cancelled', 'refunded'
- Total calculated from line items (not random)
- Timestamps are chronologically consistent (created < shipped < delivered)

PaymentFactory:
- Linked to an Order (auto-creates if needed)
- Traits: 'succeeded', 'failed', 'pending', 'refunded'
- Amount matches the associated order total

All factories should use faker.js and support overrides.
Save to /tests/factories/

Strategie fixtures według warstwy testowej

Testy jednostkowe: buduj, nie twórz w bazie

Testy jednostkowe nigdy nie powinny dotykać bazy danych. Użyj build() do tworzenia czystych obiektów.

// Dobrze: czyste obiekty, bez bazy danych
const user = UserFactory.build({ role: 'admin' });
const result = authService.checkPermission(user, 'delete_users');
expect(result).toBe(true);

Testy integracyjne: tworzenie z izolacją

Testy integracyjne potrzebują rekordów w bazie danych, ale nie mogą wylewać stanu między testami.

Wskazówka

Prompt do skopiowania — setup danych testowych dla testów integracyjnych:

Create a test data seeding utility for our integration tests:

Requirements:
1. A seed() function that creates a consistent baseline dataset:
   - 3 users (admin, regular, suspended)
   - 5 products (mix of categories, some out of stock)
   - 10 orders (various statuses across users)
   - Associated payments for completed orders

2. Runs inside a database transaction that rolls back after each test

3. Returns references to all created entities:
   const { users, products, orders } = await seed(db);
   // users.admin, users.regular, users.suspended
   // products[0], products[1], etc.

4. Relationships are consistent:
   - Orders belong to specific users
   - Payments match order totals
   - Stock levels reflect order history

Save to /tests/helpers/seed.ts

Testy E2E: stabilne dane referencyjne

Testy E2E potrzebują przewidywalnych danych utrzymujących się przez cały przebieg testu.

Wskazówka

Prompt do skopiowania — dane testowe E2E:

Create an E2E test data management system:

1. A global setup script that:
   - Resets the test database to a clean state
   - Seeds reference data (categories, settings, feature flags)
   - Creates test users with known credentials:
     - admin@test.com / TestAdmin123! (admin role)
     - user@test.com / TestUser123! (regular user)
     - premium@test.com / TestPremium123! (premium subscriber)

2. A per-test data helper that:
   - Creates test-specific data (e.g., orders for "test order cancellation" flow)
   - Tags data with the test name for cleanup
   - Cleans up after the test completes

3. A cleanup script that removes all test-tagged data without touching reference data

Save to /tests/e2e/data/
Include usage examples in each E2E test.

Generowanie danych zgodne z prywatnością

Dane produkcyjne bez prawdziwych PII

Wskazówka

Prompt do skopiowania — generowanie danych lustrzanych produkcji:

Create a data generation script that produces a production-realistic dataset
WITHOUT using any real customer data:

Requirements:
1. User distribution matches production:
   - 70% free tier, 20% premium, 10% enterprise
   - 60% US, 15% EU, 10% APAC, 15% other
   - Age distribution: normal around 32 with std dev 10
   - 30% have profile pictures, 70% do not

2. Order patterns match production:
   - Average 2.3 orders per user
   - Order values: log-normal distribution, mean $47, median $32
   - 15% of orders have been refunded
   - Seasonal pattern: 40% more orders in Q4

3. Generate 10,000 users with associated data
4. All PII is synthetic (faker.js) - zero real data
5. Save as a SQL dump for seeding staging environments

Output the generation script to /scripts/generate-staging-data.ts
Include a README explaining the data distribution assumptions.

Gdy coś się zepsuje

“Testy failują, bo fabryki generują dane naruszające reguły biznesowe.” Twoje fabryki potrzebują wiedzy domenowej. Dodaj walidację do fabryki: jeśli produkt jest “outOfStock”, stock musi być 0. Jeśli zamówienie jest “delivered”, musi mieć datę shipped_at przed delivered_at. Koduj reguły biznesowe w fabryce, nie tylko losowe dane.

“Tworzenie danych testowych jest wolne z powodu łańcuchów kluczy obcych.” Wstawiaj masowo zamiast tworzenia jednego rekordu na raz. Tworzenie współdzielonych danych referencyjnych (kategorie, role) raz w hooku beforeAll. Tworzenie danych specyficznych dla encji tylko per test.

“Plik seed ciągle rozjeżdża się ze zmianami schematu.” Generuj fabryki ze schematu, nie ręcznie. Gdy schemat się zmienia, przegeneruj: “Read the updated schema and update all factories to match. Add default values for new required columns.”

“Potrzebujemy danych produkcyjnych do debugowania, ale nie możemy ich użyć z powodu PII.” Użyj podejścia generowania zgodnego z prywatnością. Tworzenie syntetycznych danych odpowiadających rozkładom produkcyjnym. Do reprodukcji konkretnych bugów zanonimizuj rekord produkcyjny ręcznie: zamień email na faker email, imię na faker imię, ale zachowaj dane strukturalne reprodukujące buga.

Co dalej

Unit Testing Use factories in unit tests for clean, isolated testing.

Integration Testing Database-backed tests with proper data isolation.

Privacy and Data Handling Enterprise data governance for test environments.