Test-driven development w Cursor

Budujesz konwerter markdown-do-HTML dla swojego CMS. Wiesz z doświadczenia, że żadne AI nie potrafi konsekwentnie wygenerować tego za jednym razem — jest zbyt wiele przypadków brzegowych z zagnieżdżonymi listami, blokami kodu wewnątrz cytatów blokowych i encjami HTML. Tradycyjne podejście: napisz kod, przetestuj ręcznie, znajdź buga, napraw go, znajdź kolejnego buga, napraw tamtego, powtarzaj aż przestaniesz znajdować błędy (co nie oznacza, że ich nie ma).

Jest lepszy sposób. Napisz najpierw testy. Daj Cursor testy i poproś, aby implementował kod, dopóki wszystkie testy nie przejdą. Potem dodaj więcej testów przypadków brzegowych i pozwól mu iterować znowu. To TDD na autopilocie — ty definiujesz, co oznacza “poprawne”, a AI wymyśla, jak tam dojść. Steve Sewell z Builder.io opisuje to jako “tysiąc razy lepsze” niż tradycyjny workflow z AI i ma rację. AI przestaje być generatorem kodu, który potrzebuje QA, i staje się generatorem kodu, który sam sobie robi QA.

Co wyniesiesz z tej lekcji

• Workflow TDD, w którym Cursor najpierw pisze testy, potem implementuje i iteruje, aż wszystko jest zielone
• Szablon promptu do generowania zestawów testów bogatych w przypadki brzegowe, które łapią bugi typowo wprowadzane przez AI
• Technikę iteracyjnego rozszerzania istniejących zestawów testów przez wklejanie awarii produkcyjnych jako nowe test case’y
• Prompt walidacji pre-PR, który uruchamia build, lint i zestaw testów, a następnie automatycznie naprawia awarie
• Zrozumienie, kiedy TDD z AI działa znakomicie, a kiedy się sypie

Workflow

Krok 1: Zdefiniuj kontrakt testami

Zacznij od tego, że Agent pisze zestaw testów. Kluczowy insight: testy napisane przed implementacją to specyfikacja, nie tylko weryfikacja. Definiują dokładnie, co kod powinien robić.

Wskazówka

Prompt do skopiowania — Specyfikacja test-first:

Utwórz kompleksowy zestaw testów w src/lib/markdown/tests/markdown-to-html.test.ts dla konwertera markdown-do-HTML.

Napisz najpierw testy. NIE pisz jeszcze implementacji.

Testuj te kategorie:

1. Nagłówki: h1 do h6, z formatowaniem inline wewnątrz nagłówków
2. Akapity: zwykły tekst, wiele akapitów rozdzielonych pustymi liniami
3. Wyróżnienie: kursywa, pogrubienie, pogrubiona kursywa, przekreślenie
4. Linki: tekst, tekst, autolinki
5. Obrazy: ![alt](src), z atrybutem title
6. Kod: inline code, ogrodzone bloki kodu z podpowiedziami języka, bloki kodu z wcięciem
7. Listy: nieuporządkowane (-, *, +), uporządkowane (1.), zagnieżdżone listy do 3 poziomów, mieszane typy list
8. Cytaty blokowe: jeden poziom, zagnieżdżone, z innymi elementami wewnątrz
9. Encje HTML: & < > ” i encje numeryczne
10. Przypadki brzegowe: pusty input, same białe znaki, ekstremalnie długie linie, niezamknięte formatowanie

Każdy test powinien mieć jasny opis tego, co testuje. Użyj vitest. Utwórz stubową implementację w src/lib/markdown/markdown-to-html.ts, która eksportuje sygnaturę funkcji, ale rzuca “Not implemented”.

Agent utworzy kompleksowy plik testowy z 30-50 test case’ami i stubową implementację. Uruchom testy — wszystkie powinny padać (poza potencjalnie testami dla pustego/białego inputu).

Krok 2: Implementuj, aż wszystkie testy przejdą

Teraz oddaj testy Agentowi i poproś go o implementację kodu. Z włączonym auto-run, Agent napisze kod, uruchomi testy, zobaczy awarie i naprawi je w pętli.

Wskazówka

Prompt do skopiowania — Implementuj do przejścia testów:

@src/lib/markdown/tests/markdown-to-html.test.ts @src/lib/markdown/markdown-to-html.ts

Zaimplementuj konwerter markdown-do-HTML w src/lib/markdown/markdown-to-html.ts.

Zasady:

1. Uruchom testy po napisaniu implementacji
2. Jeśli jakiekolwiek testy padają, napraw implementację (NIE testy) i uruchom ponownie
3. Iteruj, aż WSZYSTKIE testy przejdą
4. Nie używaj żadnej zewnętrznej biblioteki do parsowania markdown — implementuj od zera
5. Jeśli jakiś test wydaje ci się błędny, powiedz mi który i dlaczego, ale nie zmieniaj go bez mojej zgody

Testy to specyfikacja. Implementacja musi się dostosować do testów, nie odwrotnie.

Tu auto-run (czyli to, co wcześniej nazywano “YOLO mode”) się opłaca. Agent uruchomi vitest, zobaczy 40 awarii, naprawi najczęstsze problemy parsowania, uruchomi ponownie, zobaczy 15 awarii, naprawi tamte i tak dalej. Monitorujesz postęp, ale nie musisz interweniować, chyba że utknie w pętli.

Krok 3: Dodaj przypadki brzegowe z rzeczywistych awarii

Gdy wszystkie początkowe testy przejdą, dodaj więcej testów opartych na markdownie, jaki faktycznie spotykasz na produkcji. Tu wklejasz prawdziwe treści, które zepsuły poprzednie implementacje.

@src/lib/markdown/__tests__/markdown-to-html.test.ts

Dodaj te dodatkowe test case'y oparte na rzeczywistym markdownie, który widzieliśmy psuć parsery:

1. Blok kodu zawierający składnię markdown (NIE powinien być parsowany)
2. Link wewnątrz nagłówka: ## [Kliknij tutaj](url)
3. Kolejne cytaty blokowe z różną zawartością
4. Element listy rozciągający się na wiele linii z wcięciem kontynuacji
5. Obraz wewnątrz linka: [![alt](img-src)](link-url)
6. Mieszany HTML i markdown: <div>**pogrubienie wewnątrz div**</div>
7. Składnia tabel ze wskaźnikami wyrównania (|:---|:---:|---:|)

Uruchom testy. Jeśli jakiekolwiek nowe testy padają, napraw implementację i iteruj, aż wszystkie przejdą.

Krok 4: Pętla walidacji pre-PR

To jest workflow, który wiąże testowanie z twoim codziennym cyklem deweloperskim. Przed otwarciem każdego PR, poproś Agenta o uruchomienie pełnego zestawu walidacji i naprawienie tego, co znajdzie.

Wskazówka

Prompt do skopiowania — Walidacja pre-PR:

Uruchom następujące sprawdzenia po kolei. Dla każdej awarii napraw ją i ponownie uruchom to sprawdzenie przed przejściem do następnego:

1. npx tsc --noEmit — Napraw wszelkie błędy TypeScript
2. npx eslint src/ --ext .ts,.tsx — Napraw wszelkie błędy lint (najpierw auto-fixable, potem ręczne)
3. npx vitest run — Napraw wszelkie awarie testów (napraw kod, nie testy)
4. npx vitest run --coverage — Zaraportuj pokrycie. Jeśli jakikolwiek plik w src/lib/ jest poniżej 80% pokrycia linii, napisz dodatkowe testy, aby pokryć luki

Zatrzymaj się dopiero, gdy wszystkie 4 sprawdzenia przejdą czysto po kolei. Pokaż mi podsumowanie tego, co zmieniłeś.

Ten jeden prompt zastępuje ręczną listę kontrolną pre-PR. Uruchamia szybkie sprawdzenia najpierw (kompilacja TypeScript, lint) przed wolniejszymi (zestaw testów, pokrycie) i naprawia problemy w miarę ich znajdowania. Niektórzy programiści uruchamiają to na końcu każdej sesji kodowania.

Krok 5: Naprawy błędów sterowane testami

Gdy przychodzi zgłoszenie błędu, zamień je w padający test, zanim zaczniesz badać poprawkę. To gwarantuje, że błąd jest naprawiony i pozostaje naprawiony.

Zgłoszenie błędu: Gdy użytkownik wkleja markdown z zakończeniami linii w stylu Windows (\r\n),
konwerter produkuje output HTML z podwójnymi odstępami.

1. Napisz padający test, który odtwarza dokładnie to zachowanie
2. Uruchom go, aby potwierdzić, że pada
3. Napraw implementację
4. Uruchom WSZYSTKIE testy, aby potwierdzić, że poprawka nie psuje niczego innego
5. Test powinien pozostać w zestawie na stałe jako ochrona przed regresją

Krok 6: Testowanie komponentów dla kodu UI

TDD działa też dla komponentów React, choć pętla feedbacku jest nieco inna.

@src/components/data-table.tsx

Napisz testy dla komponentu DataTable za pomocą vitest i @testing-library/react:

1. Renderuje prawidłową liczbę wierszy z propa data
2. Kliknięcie nagłówka kolumny wywołuje onSort z nazwą kolumny
3. Pokazuje stan pusty, gdy data jest pustą tablicą
4. Pokazuje wiersze skeleton, gdy isLoading jest true
5. Stosuje prawidłowy atrybut aria-sort do posortowanej kolumny
6. Nawigacja klawiaturą: Tab focusuje pierwszy sortowalny nagłówek, Enter wyzwala sortowanie

Uruchom testy na istniejącym komponencie. Jeśli jakiekolwiek padają, powiedz mi,
czy oczekiwanie testu jest błędne, czy komponent wymaga naprawy.

Kiedy TDD z AI działa najlepiej

Podejście TDD z AI działa znakomicie dla:

• Czystych funkcji z jasnymi wejściami i wyjściami (parsery, formatery, walidatory, kalkulatory)
• Handlerów endpointów API, gdzie możesz zdefiniować kontrakty request/response jako testy
• Logiki transformacji danych, gdzie przypadki brzegowe są dobrze zdefiniowane
• Napraw błędów, gdzie błąd można wyrazić jako padający test

Działa gorzej dla:

• Layoutu UI i designu wizualnego (testy nie mogą zweryfikować, czy coś “dobrze wygląda”)
• Złożonej logiki integracji, gdzie setup testów to więcej kodu niż implementacja
• Optymalizacji wydajności, gdzie testy poprawności przechodzą, ale kod jest za wolny

Dla słabych stron łącz TDD z innymi technikami: przegląd wizualny dla UI, benchmarki dla wydajności, testy integracyjne z prawdziwymi serwisami dla złożonej orkiestracji.

Kiedy to się psuje

Agent modyfikuje testy, aby przeszły. To najgroźniejszy tryb awarii. Prompt mówi “napraw implementację, nie testy”, ale pod presją (wiele padających testów) AI czasem idzie na skróty. Zawsze diffuj plik testowy po rundzie implementacji. Jeśli testy się zmieniły, odrzuć i uruchom ponownie.

Testy są zbyt sprzężone z detalami implementacji. Jeśli twoje testy sprawdzają, czy konkretna wewnętrzna funkcja została wywołana lub czy powstała określona pośrednia struktura danych, stają się kruche. Testuj interfejs publiczny — wejścia i wyjścia — nie ścieżkę implementacji. Dodaj regułę do .cursor/rules: “Testy powinny assertować tylko na zwracanych wartościach publicznych funkcji i efektach ubocznych, nigdy na wewnętrznych detalach implementacji.”

AI pisze testy, które przechodzą trywialnie. Uważaj na testy typu expect(result).toBeDefined() lub expect(typeof result).toBe('string') — te przechodzą dla praktycznie każdej implementacji. Testy powinny assertować konkretne wartości: expect(result).toBe('<h1>Hello</h1>').

Raport pokrycia mówi 95%, ale bugi nadal się wymykają. Pokrycie linii jest konieczne, ale nie wystarczające. Dodaj wymagania pokrycia gałęzi i testy mutacyjne. Agent może skonfigurować Stryker mutation testing, aby zweryfikować, że twoje testy faktycznie łapią bugi, a nie tylko wykonują ścieżki kodu.

Pętla TDD się zacina. Jeśli Agent nie robi postępu po 3-4 iteracjach (liczba testów zostaje taka sama), pozostałe testy prawdopodobnie ujawniają fundamentalny problem projektowy. Zatrzymaj pętlę, użyj trybu Ask, aby przeanalizować padające testy, i rozważ, czy podejście implementacyjne wymaga zmiany, zamiast łatać pojedyncze awarie testów.

Co dalej

Optymalizacja wydajności Gdy testy przejdą, sprofiluj kod i zoptymalizuj wolne części z pewnością siebie.

Audyt bezpieczeństwa Użyj zestawu testów jako fundamentu do testowania ukierunkowanego na bezpieczeństwo.

Wzorce testowania Zaawansowane strategie i wzorce testowania dla różnych typów aplikacji.