Strategie i generowanie testów jednostkowych

Prosisz AI o “napisz testy jednostkowe dla UserService” i generuje 40 testów. Wszystkie przechodzą. Pokrycie wynosi 95%. Czujesz się dobrze, aż klient zgłasza, że użytkownicy z plusami w adresach email nie mogą się zarejestrować. Żaden z tych 40 testów nie pokrywał tego przypadku, ponieważ AI testowało happy path na 40 nieco różnych sposobów. Ilość to nie pokrycie. Właściwe testy na właściwych granicach łapią błędy — a to wymaga specyficznego, świadomego promptowania.

Co wyniesiesz

Wzorce promptów generujące testy skupione na zachowaniu i przypadkach brzegowych, nie tylko pokryciu linii
Strategie mockowania utrzymujące testy szybkie i niezawodne bez nadmiernego mockowania
Techniki testowania obsługi błędów, współbieżności i warunków brzegowych
Przepływy pracy dla utrzymywania testów w miarę ewolucji kodu
Integracja testowania mutacyjnego dla weryfikacji, że testy faktycznie łapią błędy

Podejście behavior-first

Najbardziej efektywne testy generowane przez AI opisują co kod powinien robić, nie jak robi to wewnętrznie.

Otwórz plik do testowania i użyj trybu Agent:

@src/services/order.service.ts
Wygeneruj testy jednostkowe dla OrderService.calculateTotal. Skup się na ZACHOWANIU:

1. "should apply percentage discount correctly" (10% zniżki z $100 = $90)
2. "should apply fixed discount correctly" ($15 zniżki z $100 = $85)
3. "should not allow total below zero" (zniżka > suma częściowa)
4. "should calculate tax after discount" (podatek od kwoty po zniżce, nie oryginalnej)
5. "should handle empty cart" (zero pozycji, bez zniżki)
6. "should round to 2 decimal places" (unikaj dziwactw floating point)
7. "should reject negative quantities" (rzuć ValidationError)
8. "should handle mixed currency items" (rzuć CurrencyMismatchError)

Testuj tylko przez publiczne API. Nie mockuj metod wewnętrznych.
Mockuj tylko bazę danych i zależności zewnętrznych serwisów.
Podążaj za wzorcami w @src/services/__tests__/payment.service.test.ts

claude "Przeczytaj /src/services/order.service.ts i wygeneruj testy jednostkowe skupione na zachowaniu.

Dla calculateTotal, testuj te zachowania:
1. Zniżki procentowe stosowane poprawnie
2. Zniżki kwotowe stosowane poprawnie
3. Suma nigdy nie schodzi poniżej zera
4. Podatek liczony od kwoty po zniżce
5. Obsługa pustego koszyka
6. Precyzja floating point (zaokrąglenie do 2 miejsc po przecinku)
7. Odrzucanie ujemnych ilości
8. Odrzucanie mieszanych walut

Mockuj TYLKO: OrderRepository, TaxService, DiscountService
NIE mockuj: metod wewnętrznych, funkcji pomocniczych
Użyj Jest + TypeScript. Zapisz do /src/services/__tests__/order.service.test.ts
Uruchom testy po ich wygenerowaniu. Napraw wszelkie błędy."

Wygeneruj testy jednostkowe oparte na zachowaniu dla OrderService.calculateTotal.

Testuj każdą regułę biznesową niezależnie:
- Zastosowanie zniżki (procentowej i kwotowej)
- Timing kalkulacji podatku (po zniżce)
- Warunki brzegowe (pusty koszyk, zero suma, wartości max)
- Warunki błędów (ujemne ilości, niezgodność walut)
- Obsługa precyzji (zaokrąglanie floating point)

Podążaj za istniejącymi konwencjami testowymi w projekcie.
Uruchom suite testowy po wygenerowaniu. Napraw wszelkie problemy.
Stwórz PR z nowymi testami.

Inteligentne strategie mockowania

Reguła granicy: Mockuj na granicy, nie wewnętrznie

Prompt do skopiowania dla właściwego mockowania:

Wygeneruj testy dla AuthService.login z tymi regułami mockowania:

MOCKUJ te (granice zewnętrzne):
- UserRepository.findByEmail (baza danych)
- BcryptService.compare (ufamy, że bcrypt działa - mockuj dla szybkości)
- TokenService.generate (zewnętrzny serwis podpisywania)

NIE MOCKUJ tych (logika wewnętrzna pod testem):
- Wewnętrzna logika walidacji AuthService
- Sanityzacja inputu
- Logika rate limiting
- Wywołania audit logging (zweryfikuj, że są wywoływane poprawnie)

Dla każdego mocka, pokaż zarówno setup "happy" jak i setup "failure".
Przykład: UserRepository.findByEmail powinno zwracać obiekt user dla testów sukcesu
i null dla testów "user not found" i rzucać dla testów "database down".

Fabryki danych testowych

Przestań hardcodować dane testowe. Używaj fabryk generujących realistyczne dane z nadpisywalnymi domyślnymi wartościami.

Prompt do skopiowania dla fabryk testowych:

Stwórz fabrykę danych testowych dla naszej encji User w /src/test/factories/user.factory.ts.

Encja User ma: id (uuid), email (string), name (string), hashedPassword (string),
role (admin | user | moderator), status (active | suspended | pending),
createdAt (Date), lastLoginAt (Date | null), preferences (obiekt JSON).

Fabryka powinna:
1. Używać faker.js do generowania realistycznych danych
2. Mieć metodę build() zwracającą czysty obiekt (dla testów jednostkowych)
3. Mieć metodę create() która zapisuje do testowej bazy (dla testów integracyjnych)
4. Wspierać nadpisywanie: UserFactory.build({ role: 'admin' })
5. Wspierać traits: UserFactory.build('suspended') dla powszechnych konfiguracji
6. Generować UNIKALNE emaile nawet gdy wywoływane masowo
7. Mieć metodę buildList(count) do generowania tablic

Uwzględnij te traits:
- 'admin': role=admin, status=active
- 'suspended': status=suspended, lastLoginAt=null
- 'newUser': createdAt w ciągu ostatnich 24 godzin, lastLoginAt=null
- 'powerUser': role=moderator, lastLoginAt w ciągu ostatniej godziny

Testowanie obsługi błędów

Obsługa błędów to miejsce, gdzie większość testów generowanych przez AI jest najsłabsza. Promptuj specyficznie dla scenariuszy błędów.

Prompt do skopiowania dla testów obsługi błędów:

Wygeneruj testy obsługi błędów dla PaymentService.processPayment:

Testuj każdy tryb błędu niezależnie:
1. Timeout sieci do dostawcy płatności (powinno retry 3 razy, potem rzucić TimeoutError)
2. Dostawca płatności zwraca 402 (niewystarczające środki - powinno rzucić PaymentDeclinedError z przyczyną)
3. Dostawca płatności zwraca 500 (powinno retry raz, potem rzucić ProviderError)
4. Klucz idempotentności już użyty (powinno zwrócić oryginalny wynik, nie retry)
5. Baza danych zawodzi przy zapisie rekordu płatności (NIE powinno odwracać opłaty - loguj do ręcznego przeglądu)
6. Nieprawidłowa kwota (zero, ujemna, > $10,000 - powinno rzucić ValidationError przed wywołaniem dostawcy)
7. Wygasła metoda płatności (powinno rzucić PaymentMethodExpiredError z przyjazną dla użytkownika wiadomością)

Dla każdego testu błędu, zweryfikuj:
- Rzucany jest poprawny TYP błędu (nie tylko jakikolwiek błąd)
- WIADOMOŚĆ błędu jest konkretna i wykonalna
- Efekty uboczne są obsługiwane poprawnie (rollback, logging, powiadomienia)
- Błąd NIE jest cicho połykany

Testowanie współbieżności

Narzędzia AI mogą generować testy współbieżności, które większość deweloperów pomija.

Prompt do skopiowania dla testów współbieżności:

Wygeneruj testy współbieżności dla InventoryService.reserveStock:

1. Dwa żądania dla tego samego przedmiotu przychodzące jednocześnie:
   - Tylko jedno powinno się powieść jeśli stock = 1
   - Oba powinny się powieść jeśli stock >= 2
   - Żadne nie powinno skutkować ujemnym stockiem

2. Reserve i cancel ścigające się:
   - Rezerwacja i jej anulowanie przychodzące w tym samym czasie
   - Stan końcowy powinien być spójny (albo zarezerwowane albo anulowane, nie uszkodzone)

3. Rezerwacja masowa:
   - 100 współbieżnych rezerwacji dla przedmiotu ze stockiem = 50
   - Dokładnie 50 powinno się powieść, 50 powinno zawieść
   - Całkowita liczba zarezerwowanych nigdy nie powinna przekroczyć stocku

Użyj Promise.all dla symulacji współbieżności. Dodaj asercje czasowe do wykrywania
kiedy operacje faktycznie wykonują się równolegle vs. są serializowane.

Testowanie mutacyjne: Udowadnianie, że Twoje testy działają

Metryki pokrycia kłamią. Test wykonujący linię niekoniecznie weryfikuje jej zachowanie. Testowanie mutacyjne wprowadza małe zmiany (mutacje) do twojego kodu i sprawdza, czy testy je łapią.

Zainstaluj Stryker Mutator

npm install --save-dev @stryker-mutator/core @stryker-mutator/jest-runner @stryker-mutator/typescript-checker

Skonfiguruj dla swojego projektu

npx stryker init
# Wybierz runner Jest, checker TypeScript
# Ustaw mutate na: src/services/**/*.ts (zacznij od małego)

Uruchom i przeanalizuj wyniki

npx stryker run
# Przejrzyj raport HTML - skup się na przeżywających mutacjach

Użyj AI do zabicia przeżywających mutantów

Podaj przeżywające mutacje z powrotem do AI dla ukierunkowanego generowania testów.

Prompt do skopiowania dla zabijania przeżywających mutacji:

Testowanie mutacyjne Stryker znalazło te przeżywające mutacje w OrderService.calculateTotal:

1. Linia 42: Zmieniono `total > 0` na `total >= 0` - PRZEŻYŁO (żaden test tego nie łapie)
2. Linia 58: Zmieniono `discount * 0.01` na `discount * 0.02` - PRZEŻYŁO
3. Linia 71: Usunięto wywołanie `Math.round(total * 100) / 100` - PRZEŻYŁO

Dla każdej przeżywającej mutacji, napisz test który by ZAWIEDZIŁ jeśli ta mutacja została zastosowana:
1. Test gdzie total wynosi dokładnie 0 i zachowanie powinno się różnić od dodatniego
2. Test ze znanym procentem zniżki weryfikujący dokładną kwotę wyjściową
3. Test gdzie kalkulacja produkuje więcej niż 2 miejsca po przecinku i asertuje zaokrąglenie

Te testy powinny być minimalne - testuj dokładnie granicę mutacji, nic więcej.

Utrzymanie testów

Aktualizacja testów wspomagana przez AI

Kiedy twoja implementacja się zmienia, AI może inteligentnie zaktualizować testy.

Prompt do skopiowania dla utrzymania testów:

Zrefaktoryzowałem UserService.createUser aby zwracał Result<User, CreateUserError>
zamiast rzucać wyjątki. Zaktualizuj plik testowy w
/src/services/__tests__/user.service.test.ts:

1. Zmień wszystkie `expect(...).rejects.toThrow(...)` aby sprawdzać wariant error Result
2. Zmień asercje sukcesu aby sprawdzać wariant success Result
3. Zachowaj te same scenariusze testowe - zmień tylko sposób asercji wyników
4. NIE dodawaj ani nie usuwaj testów - tylko zaktualizuj wzorzec asercji
5. Uruchom testy po aktualizacji aby zweryfikować, że przechodzą

Pokaż mi diff tego co się zmieniło abym mógł zweryfikować, że logika testów nie została zmieniona.

Kiedy to się psuje

“AI generuje testy, które wszystkie wyglądają tak samo.” Podałeś ogólny prompt. Bądź specyficzny co do scenariuszy, które chcesz przetestować. Wypisz przypadki brzegowe, warunki błędów i wartości graniczne wprost.

“Testy przechodzą lokalnie ale zawodzą w CI.” Sprawdź problemy z izolacją testów. Testy generowane przez AI czasami dzielą zmienialny stan między testami. Upewnij się, że beforeEach resetuje wszystkie mocki i stan testowy. Dodaj --runInBand do CI jeśli testy mają ukryte problemy z równoległością.

“Wynik mutacji jest niski pomimo wysokiego pokrycia.” Twoje testy wykonują kod bez weryfikowania jego outputu. Skup się na dodawaniu asercji dla wartości zwracanych, efektów ubocznych i warunków błędów. Pokrycie bez asercji jest bez sensu.

“Suite testowy jest wolny po tym jak AI wygenerowało setki testów.” Przejrzyj pod kątem redundancji. Zapytaj AI: “Przeanalizuj te testy i zidentyfikuj zestawy pokrywające te same ścieżki kodu. Które testy można usunąć bez zmniejszenia pokrycia mutacyjnego?”

Co dalej

Integration Testing Testuj interakcje serwisów i operacje na bazach danych z AI.

Test Data Management Fabryki, fixtures i generowanie danych dla spójnego testowania.

E2E Testing Automatyzuj testowanie ścieżek użytkownika od rejestracji do kasy.