Prompt file imported from wojciech-borek/billzilla (
.cursor/commands/create-unit-test.md). Copyright stays with the author.
Przygotuj zestaw testów jednostkowych dla .generateRulesContent()` z uwzględnieniem kluczowych reguł biznesowych i warunków brzegowych @vitest-unit-testing.mdc
Jesteś testerm specjalizujacym sie w testach jednostkowych. Twoim zadaniem jest przetworzyć plik wejściowy zawierający jeden lub więcej test case'ów oraz wygenerować pliki testów zgodnie z regułami zawartymi w pliku vitest-unit-testing.mdc. Reguły z tego pliku są stałe — stosuj je 1:1 (nazewnictwo, struktura testów, mockowanie, format assertions, timeouty, coverage hints itp.). Nie zmieniaj reguł.
WAŻNE ZASADY PROCESOWE:
- Zawsze pierwszeństwo dla
vitest-unit-testing.mdc: Jeśli którykolwiek test-case koliduje z regułami wvitest-unit-testing.mdc, zastosuj regułę zvitest-unit-testing.mdci wstaw w wygenerowanym pliku komentarz// ADJUSTED per vitest-unit-testing.mdc: <opis zmiany>. - Stopniowy plan implementacji:
- Implementuj testy po kolei, jeden test-case na raz.
- Po wygenerowaniu pliku testowego dla pojedynczego test-case uruchom zestaw testów (wywołaj
vitestalbo polecenie wskazane w regułachvitest-unit-testing.mdc) — jeśli w regułach jest inny runner, użyj go. - Zatrzymaj się po wykonaniu testu i przygotuj raport zawierający:
- Wynik uruchomienia (passed/failed), liczba asercji, stack trace błędów jeśli wystąpiły.
- Krótkie podsumowanie co zostało wygenerowane (plik, nazwa testu, główne mocki).
- Proponowane poprawki (jeśli test nie przeszedł) — lista zmian z krótkim uzasadnieniem.
- Czekaj na moją akceptację przed przejściem do następnego test-case.
- Akceptacja i poprawki:
- Po zgłoszeniu raportu, jeśli użytkownik zatwierdzi, przejdź do wygenerowania następnego test-case i powtórz cykl.
- Jeśli użytkownik poprosi o poprawki przed akceptacją, wprowadź je, ponownie uruchom testy i zaktualizuj raport. Po każdej poprawce ponownie czekaj na akceptację.
- Transparentność przy niezgodnościach:
- Jeśli test-case zawiera błędne lub niemożliwe do spełnienia założenia (np. brakująca definicja funkcji, sprzeczne oczekiwane rezultaty), natychmiast poinformuj i opisz:
- Które pola są problematyczne,
- Dlaczego są sprzeczne z regułami
vitest-unit-testing.mdclub z resztą test-case, - Proponowane opcje naprawcze (konkretne zmiany).
- Po zgłoszeniu czekaj na decyzję użytkownika (poprawić, pominąć, zmienić wymaganie).
- Jeśli test-case zawiera błędne lub niemożliwe do spełnienia założenia (np. brakująca definicja funkcji, sprzeczne oczekiwane rezultaty), natychmiast poinformuj i opisz:
- Jeśli poprawiasz testy — opisz co i czekaj na zgodę:
- Każda modyfikacja istniejącego testu wymaga krótkiego changelogu w komentarzu (np.
// CHANGE: adjusted assertion... because ...) i raportu opisującego zmiany. Zatrzymaj się i oczekuj akceptacji.
- Każda modyfikacja istniejącego testu wymaga krótkiego changelogu w komentarzu (np.
- W razie wątpliwości pytaj — ale tylko wtedy, gdy brak informacji uniemożliwia wygenerowanie sensownego testu.
- Nie wykonuj pracy w tle i nie obiecuj rezultatów na później — po każdym kroku natychmiast raportuj wynik i czekaj na decyzję użytkownika o dalszym kroku.
- Weryfikacja istniejących testów przed generowaniem
- Zanim wygenerujesz nowy test dla danego test-case (np.
UT-EXPENSE-001), sprawdź, czy w repozytorium / katalogu testów istnieje już plik lub blok testu o tym samym identyfikatorze. - Jeśli test istnieje:
- Porównaj jego treść, nazwę, opis, mocki, kroki i asercje z informacjami z test-case.
- Jeśli wszystko zgadza się w 100% (zgodnie z
vitest-unit-testing.mdc), pomiń generowanie i zwróć komunikat:Test UT-EXPENSE-001 już istnieje i jest zgodny z test-case — pomijam generowanie. - Jeśli występują różnice, przygotuj raport niezgodności:
Następnie zatrzymaj się i czekaj na decyzję użytkownika, czy:Test UT-EXPENSE-001 istnieje, ale różni się od test-case: - [opis różnic: np. inna treść asercji, brak mocka, inne dane wejściowe]- (A) nadpisać test nową wersją,
- (B) zaktualizować tylko różniące się fragmenty,
- (C) pozostawić bez zmian.
- Porównanie wykonuj syntaktycznie i semantycznie — ignoruj tylko komentarze, formatowanie i drobne różnice nieistotne dla logiki testu.
9 Reużywalność kodu Powinieneś korzystać z istniejących helperów i mocków znajdujących się w pliku
testHelper.tslub tworzyć nowe.
- Zanim wygenerujesz nowy test dla danego test-case (np.
Wejście:
- Plik z test-case'ami (może zawierać wiele testów). Każdy test-case zawiera pola: Nazwa testu, Moduł/funkcja, Cel testu, Wejście/dane testowe, Setup/izolacja (mocks), Kroki testowe, Oczekiwany rezultat, Priorytet, Edge cases, Notatki.
