Wzorce testowania

Właśnie skończyłeś implementację serwisu przetwarzania płatności. Działa w twoich testach ręcznych, ale nie masz automatycznych testów. Pisanie testów dla 15 funkcji obejmujących tworzenie płatności, walidację, zwroty i obsługę webhooków wydaje się zajmować więcej czasu niż napisanie samego serwisu. Więc wysyłasz go bez testów, obiecując sobie, że dodasz je później. Dwa tygodnie później refaktoryzacja psuje logikę zwrotów i nikt tego nie wyłapuje, dopóki klient nie zgłosi problemu.

AI jest wyjątkowo dobre w pisaniu testów. Może przeanalizować twój kod, zidentyfikować ważne ścieżki i przypadki brzegowe, i wygenerować kompleksowy zestaw testów w kilka minut. Kluczem jest wiedza, jak promptować o testy, które faktycznie wyłapują błędy, a nie testy, które po prostu osiągają liczby pokrycia.

Czego się nauczysz

• Workflow generowania kompleksowych zestawów testów z istniejącego kodu
• Wzorzec TDD z AI (najpierw pisz testy, potem implementację)
• Techniki dodawania testów do nietestowanego kodu legacy
• Gotowe prompty do skopiowania, które produkują wysokiej jakości, łatwe w utrzymaniu testy

Wzorzec test-first (TDD z AI)

Najpotężniejszy wzorzec testowania z AI: najpierw napisz testy, potem pozwól agentowi napisać implementację i iterować, aż testy przejdą.

Wskazówka

Prompt do skopiowania — TDD:

I need a function that converts Markdown to HTML.

Step 1: Write tests first in src/utils/__tests__/markdown-to-html.test.ts

Test cases to cover:
- Basic formatting: bold, italic, links, headings (h1-h6)
- Code blocks: inline code and fenced code blocks with language tags
- Lists: ordered and unordered, including nested lists
- Edge cases: empty string, null input, malformed markdown, HTML entities
- Security: XSS prevention (script tags should be escaped)

Step 2: Implement the function in src/utils/markdown-to-html.ts

Step 3: Run the tests. Fix any failures. Repeat until all tests pass.

Use the test patterns from @src/utils/__tests__/date-utils.test.ts.

Dlaczego to działa: AI pisze testy na podstawie twojej specyfikacji oczekiwanego zachowania. Potem pisze implementację, która przechodzi te testy. Jeśli test nie przechodzi, implementacja jest błędna (nie test), więc AI naprawia implementację. To zapobiega częstemu problemowi “naprawiania” testów przez AI, aby pasowały do wadliwego kodu.

Generowanie testów dla istniejącego kodu

Generowanie kompleksowego zestawu testów

Wskazówka

Prompt do skopiowania — generowanie testów:

Write a comprehensive test suite for @src/services/payment-service.ts.

Requirements:
- Test file: src/services/__tests__/payment-service.test.ts
- Framework: Vitest
- Mock all external dependencies (Stripe SDK, database, email service)
- Use factory functions for test data

For each public function, test:
1. Happy path with valid inputs
2. Validation errors (invalid inputs, missing required fields)
3. External service failures (Stripe returns error, database timeout)
4. Edge cases (zero amounts, currency mismatches, duplicate payments)
5. Authorization errors (user does not have permission)

Name tests descriptively: "should [behavior] when [condition]"

Follow the testing patterns in @src/services/__tests__/user-service.test.ts.
Run the tests after writing them.

Dodawanie testów do kodu legacy

Dla nietestowanego kodu, gdy nie jesteś pewien, co robi:

Wskazówka

Prompt do skopiowania — testy charakteryzujące:

@src/services/legacy-pricing-engine.ts has no tests and the business logic is complex.

Write characterization tests that document the current behavior:
1. Read the code and identify every public function
2. For each function, determine what it does based on the implementation
3. Write tests that assert the current behavior (even if the behavior seems wrong)
4. Mark any tests where the behavior seems like a potential bug with a TODO comment

These tests are not validating correctness -- they are capturing existing behavior so we can refactor safely.

Test file: src/services/__tests__/legacy-pricing-engine.test.ts

Testy charakteryzujące są niezbędne przed refaktoryzacją kodu legacy. Mówią ci, kiedy refaktoryzacja zmienia zachowanie, nawet jeśli oryginalne zachowanie nie było udokumentowane.

Budowanie na istniejącym zestawie testów

Jeden z najpraktyczniejszych wzorców: przyrostowe rozszerzanie pokrycia testami poprzez analizę tego, co nie jest testowane.

Wskazówka

Prompt do skopiowania — rozszerzanie pokrycia:

Run `npm test -- --coverage` and look at the coverage report for @src/services/order-service.ts.

Identify the uncovered lines and branches. Then write additional tests that cover:
1. The uncovered error handling paths
2. The untested edge cases
3. Any branch conditions that are only partially covered

Add the new tests to the existing test file @src/services/__tests__/order-service.test.ts.
Follow the existing test style and organization.

Run the tests to make sure the new tests pass and overall coverage increased.

Wykorzystanie nieprzechodzących testów z błędów produkcyjnych

Gdy napotkasz błąd produkcyjny, pierwszym krokiem powinno być napisanie testu, który go odtwarza:

We discovered a bug: orders with decimal quantities (e.g., 2.5 units)
cause the total calculation to return NaN.

Before fixing the bug:
1. Write a failing test that demonstrates the exact bug
2. The test should pass valid decimal quantities and assert the correct total
3. Run the test to confirm it fails with the current code

Then fix the bug and confirm the test passes.

This ensures the fix actually addresses the issue and prevents regression.

Wzorzec fabryk danych testowych

Zamiast pisać inline obiekty testowe w każdym teście, stwórz funkcje fabryczne:

Wskazówka

Prompt do skopiowania — fabryki testowe:

Create a test data factory file at src/test-utils/factories.ts.

Analyze the types in @src/types/ and create factory functions for:
- createUser(overrides?) - returns a valid User object with sensible defaults
- createOrder(overrides?) - returns a valid Order with linked user
- createPayment(overrides?) - returns a valid Payment with linked order

Each factory should:
- Return complete, valid objects with default values
- Accept partial overrides to customize specific fields
- Use incrementing IDs to avoid collisions
- Generate realistic but predictable test data

Follow this pattern:
```typescript
export function createUser(overrides?: Partial<User>): User {
  return {
    id: `user-${nextId()}`,
    email: `test-${nextId()}@example.com`,
    firstName: 'Test',
    lastName: 'User',
    ...overrides,
  }
}
```

Kiedy coś nie działa

AI pisze testy, które tylko potwierdzają implementację. Jeśli test wywołuje funkcję i sprawdza, czy zwracana wartość jest tym, co funkcja zwraca, nie testuje niczego. Określ oczekiwane zachowanie jawnie w prompcie: “should return 42 when given inputs X and Y.”

Testy przechodzą, ale nie wyłapują prawdziwych błędów. Testy zbyt skupiają się na szczęśliwych ścieżkach. Zawsze jawnie żądaj testowania ścieżek błędów, przypadków brzegowych i warunków granicznych.

AI “naprawia” test zamiast kodu. Wyraźnie powiedz: “The test represents the correct behavior. The implementation is wrong. Fix the implementation.”

Wygenerowane testy są niestabilne. Testy zależne od czasu, losowych wartości lub stanu zewnętrznego są nierzetelne. Dodaj do swojej reguły testowania: “Never use real timers, random values, or network calls in unit tests. Mock everything.”

Plik testowy staje się zbyt duży. Podziel testy według domeny (testy auth, testy profilu, testy płatności) zamiast mieć jeden monolityczny plik testowy na serwis.

Co dalej

• Workflow debugowania — Testy to fundament skutecznego debugowania
• Strategie refaktoryzacji — Testy umożliwiają bezpieczną refaktoryzację
• Workflow recenzji — Recenzowanie testów generowanych przez AI obok kodu