Testowanie i debugowanie z Cursorem

Testowanie i debugowanie z Cursorem to sekcja trzech przewodników dla programistów, którzy powierzają agentowi Cursora pisanie testów i naprawianie błędów. Przewodniki pokazują, jak najpierw napisać test, który nie przechodzi, jak generować testy łapiące prawdziwe błędy w istniejącym kodzie i jak znaleźć przyczynę, zanim powstanie poprawka. Każdy kończy się dowodami, które recenzent sprawdza zamiast czytać diff.

Prosisz agenta Cursora o testy dla serwisu płatności. Pisze 30, wszystkie przechodzą, pokrycie rośnie. Tydzień później refaktor psuje zwroty i żaden test nie robi się czerwony, bo testy sprawdzały to, co kod już robił, a nie to, co powinien robić. Ta sekcja jest dla programisty, który pisze takie prompty, i dla tech leada, który decyduje, czego musi dowodzić pull request z testami.

Aktualność dokumentacji

Dotyczy linii Cursor 3.x; aktualne wydanie na 2026-10-12 to Cursor 3.24 (2026-10-09, informacje o wydaniu Cursora). Dokumentacja Cursora wymienia cztery tryby agenta: Agent, Ask, Plan i Debug, a Shift+Tab przełącza je po kolei; Cmd+I (Ctrl+I w Windows i Linuksie) otwiera panel Agenta. Tryby uruchamiania to Auto-review, Allowlist i Run Everything, a Cursor nie wskazuje jednego domyślnego modelu (wszystko sprawdzone 2026-10-12). Plan Mode, Bugbot i MCP sprawdzono na cursor.com po raz pierwszy 28 sierpnia 2026.

Którego przewodnika o testowaniu w Cursorze potrzebujesz?

Twoja sytuacja	Zacznij od	Z czym wychodzisz
Nowa funkcja albo zmiana zachowania	Test-driven development w Cursorze	Test napisany ze specyfikacji, który najpierw nie przechodzi, a potem implementacja, po której test przechodzi
Istniejący kod z nielicznymi albo słabymi testami	Wzorce testowania	Testy charakteryzacyjne, pokrycie prawdziwych przypadków brzegowych i fabryki danych testowych
Coś jest zepsute, często sporadycznie	Debugowanie z AI w Cursorze	Reprodukcja, udowodniona przyczyna i test regresyjny, który najpierw nie przechodził

Przed tą sekcją potrzebujesz działającej konfiguracji agenta i polecenia testów, które agent może uruchomić: zobacz szybki start z Cursorem i reguły projektu.

Jak przebiega pętla testowania i debugowania w Cursorze

Wszystkie trzy przewodniki trzymają się tej samej kolejności, a to ona powstrzymuje agenta przed pisaniem testów dopasowanych do własnego kodu.

1. Opisz zachowanie w Plan Mode. Plan Mode według Cursora „tworzy szczegółowe plany implementacji, zanim napisze jakikolwiek kod”. Zamień w nim zlecenie albo zgłoszenie błędu w kryteria akceptacji, bez edycji plików.

2. Napisz test i zobacz, że nie przechodzi. Przełącz się na agenta Cursora i każ mu pisać wyłącznie testy, bez dotykania plików źródłowych. Test, który przechodzi, zanim powstała zmiana, niczego nie sprawdza.

3. Implementuj przy zablokowanych testach. Agent zmienia pliki źródłowe, aż zestaw testów będzie zielony, i nie rusza testów. Najpierw zrób commit, żeby git diff --stat pokazał dokładnie, czego dotknął. Polecenie to nie blokada: wymuś je kontrolą w CI, która nie przechodzi, gdy commit z implementacją zmienia tests/ (zobacz ochrona wyroczni).

4. Uruchom wszystkie bramki. Pełny zestaw testów, sprawdzenie typów i linter, lokalnie i ponownie w CI.

5. Zleć niezależny przegląd. Bugbot albo drugi agent przegląda pull request względem kryteriów akceptacji, a nie względem podsumowania, które napisał sam agent.

Prompt do skopiowania: testy z zachowania, nie z kodu

Do not change any file under src/. Only create or edit files under tests/.

Read @src/payment/refund.ts but treat it as possibly wrong. Write tests from
these rules, not from what the code currently does:
1. A refund can never exceed the captured amount minus earlier refunds.
2. A refund on a disputed payment is rejected with REFUND_BLOCKED.
3. Two concurrent refunds for the same payment cannot both succeed.

For each test, name the bug it would catch. Run the tests and report which
fail on the current code. Do not "fix" a failing test: a failure may be a real bug.

Prompt do skopiowania: udowodnij, że nowy test potrafi nie przejść

For each test you added in this session:
1. Make the smallest change to the source that should break it (flip a
   comparison, drop a guard, return early).
2. Run only that test and confirm it fails. Paste the failure line.
3. Revert the change and confirm the test passes again.
Report any test that stayed green when the code was broken, and rewrite its
assertion. When you finish, `git diff` on src/ must be empty.

Jak ufać testom napisanym przez agenta, nie czytając ich wszystkich?

Sprawdź, czy testy potrafią nie przejść i czy nikt nie nagiął ich do kodu. Wymagaj tych dowodów w każdym pull requeście, który dodaje albo zmienia testy:

• Czerwony przed zielonym. Każdy nowy test nie przechodzi na starym kodzie, a wynik tego przebiegu trafia do pull requesta.
• Próba psucia. Drugi prompt powyżej: test, który przeżywa celowo zepsutą linię, jest dekoracją. Siła wyroczni pokazuje, jak mierzyć to w całym zestawie.
• Testy nietknięte podczas poprawki. git diff --stat dla commita z implementacją nie wymienia plików testów.
• Bramki zielone w CI, a nie tylko w raporcie agenta.

Dowody należą do programisty. Recenzent zatwierdza, gdy wszystkie punkty są obecne, i czyta kod tylko tam, gdzie czegoś brakuje albo coś zaskakuje. Uzasadnienie znajdziesz w tekście dowody zamiast czytania kodu.

Który serwer MCP pomaga w testowaniu w Cursorze?

Przy błędach interfejsu i testach end-to-end oficjalny serwer Playwright MCP (@playwright/mcp 0.0.82, sprawdzone przez npm view 26 września 2026) pozwala agentowi sterować prawdziwą przeglądarką i czytać błędy z konsoli. Dodaj go do konfiguracji MCP w Cursorze (mcp.json; zobacz konfiguracja MCP):

{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] } } }

Gdy kilka agentów testuje równolegle, dodaj --isolated do args, bo trwały profil przeglądarki można otworzyć tylko w jednej przeglądarce naraz. Schematy narzędzi i zrzuty stron zajmują kontekst, więc włączaj serwer do pracy nad UI, a nie w każdej sesji. Alternatywy porównują strony Playwright MCP i skille do testowania i debugowania.

Co się psuje przy testowaniu i debugowaniu w Cursorze?

Objaw	Prawdopodobna przyczyna	Jak to naprawić
Wszystkie nowe testy przechodzą za pierwszym razem	Wyprowadzono je z implementacji	Powtórz pierwszy prompt z wypisanymi regułami i src/ tylko do odczytu
Test, który nie przechodził, zielenieje po edycji testu	Agent zmienił asercję, żeby pasowała do kodu	Cofnij test, napisz „The test is correct; fix the implementation” i sprawdź git diff --stat
Każda poprawka psuje coś innego	Agent edytował, zanim była znana przyczyna	Wróć do ostatniego czystego commita i do Plan Mode (polowanie na błędy)
Pokrycie rośnie, a błędy dalej uciekają	Testy wykonują linie, ale nie sprawdzają wyników	Uruchom prompt z próbą psucia na module, z którego wyciekł błąd
Lokalnie zielono, w CI czerwono	Inne dane, zależności czasowe albo środowisko	Odtwórz problem poleceniem i danymi z CI, zanim poprosisz o poprawkę

Dokąd dalej po testowaniu w Cursorze

Test-driven development w Cursorze Napisz ze specyfikacji test, który nie przechodzi, a implementację zostaw agentowi.

Wzorce testowania Testy dla istniejącego i legacy kodu, które łapią prawdziwe regresje.

Debugowanie z AI w Cursorze Zbadaj bez edycji, odtwórz, napraw jedną przyczynę i udowodnij to.

Code review i wdrożenie z Cursorem Następny etap: code review, Bugbot i bramki CI przed wydaniem.

Ten sam etap w innych narzędziach: Claude Code i Codex. Praktyka niezależna od narzędzia jest w sekcji przepływy weryfikacji.