Wzorce testowania w Cursorze

Wzorce testowania w Cursorze to prompty i kontrole, dzięki którym agent Cursora pisze testy na podstawie opisanego zachowania, a nie kodu, który właśnie przeczytał. Obejmują istniejący i legacy kod, ścieżki błędów, błędy z produkcji, luki w pokryciu, dane testowe, testy w przeglądarce i niestabilne testy. Każdy wzorzec kończy się dowodem, że testy potrafią nie przejść.

Wdrożyłeś serwis płatności bez testów automatycznych. Prosisz agenta Cursora o zestaw testów: powstaje 30 testów, wszystkie zielone, pokrycie skacze do 85%. Dwa tygodnie później refaktor psuje zwroty i nic nie robi się czerwone, bo każda asercja powtarzała to, co kod już robił. Ta strona jest dla programisty, który pisze prompty, i dla tech leada, który decyduje, czego musi dowodzić pull request z testami.

Co dają ci te wzorce testowania w Cursorze

Regułę projektu i ustawienie trybu uruchamiania, dzięki którym agent sam uruchamia testy, ale nie wykona niczego destrukcyjnego
Osiem promptów do skopiowania: zestawy testów z zachowania, ścieżki asynchroniczne i błędów, testy charakteryzacyjne, błąd jako nieprzechodzący test, luki w pokryciu, fabryki danych testowych, testy end-to-end z Playwright i diagnozę niestabilnych testów
Pięciopunktową listę dowodów, która mówi, czy testy napisane przez agenta potrafią złapać błąd, bez czytania każdego testu
Tabelę typowych awarii testów pisanych przez agenta i sposobów wyjścia z każdej

Który wzorzec testowania pasuje do twojego kodu?

Wybierz wzorzec według tego, co wiesz o poprawnym zachowaniu. Źródło „poprawności” (wyrocznia) decyduje, co testy mogą sprawdzać.

Twoja sytuacja	Wzorzec	Skąd pochodzi „poprawne”
Nowa funkcja albo zmiana zachowania	Test-driven development w Cursorze	Twoja specyfikacja, napisana przed kodem
Działający kod, mało albo słabe testy, znane reguły	Zestaw testów z zachowania	Reguły biznesowe podane w prompcie
Kod legacy, którego nikt w pełni nie rozumie	Testy charakteryzacyjne	Obecne zachowanie, zapisane przed zmianą
Błąd trafił na produkcję	Błąd jako nieprzechodzący test	Zgłoszenie błędu
Raport pokrycia pokazuje nietestowane gałęzie	Luki w pokryciu	Reguły stojące za każdą niepokrytą gałęzią
Ścieżka użytkownika przechodzi przez strony i serwisy	Testy end-to-end z Playwright MCP	Kryteria akceptacji ścieżki
Test pada raz na dziesięć uruchomień	Diagnoza niestabilnego testu	Intencja testu, uczyniona deterministyczną

Przygotuj Cursora, żeby agent bezpiecznie uruchamiał testy

Każdy wzorzec poniżej wymaga, by agent uruchomił zestaw testów, przeczytał błąd i spróbował ponownie. Skonfiguruj to raz na repozytorium.

Pozwól uruchamiać polecenia testowe bez pytania. O tym, które polecenia terminala agent uruchamia bez pytania, Cursor decyduje w trybach uruchamiania (strona Run modes w sekcji Agent security dokumentacji Cursora, sprawdzona 28 sierpnia 2026). Nazw trybów i ścieżki ustawień nie dało się ponownie sprawdzić 26 września 2026, więc zweryfikuj je w swojej wersji. Wybierz tryb, który swobodnie uruchamia testy, sprawdzanie typów i linter, ale pyta przed wszystkim, co usuwa dane albo dotyka zdalnego repozytorium. Nie używaj trybu, który uruchamia każde polecenie bez nadzoru, poza jednorazowym sandboksem z ograniczoną siecią.
Zapisz konwencje testowe w regule projektu. Reguła trzyma konwencje w każdej sesji, więc nie powtarzasz ich w każdym prompcie. Zakresy i położenie plików opisuje strona o regułach projektu.
Zrób commit, zanim agent zacznie. Czysty commit sprawia, że git diff --stat pokazuje dokładnie, których plików dotknął agent, i tak wyłapiesz zmienioną asercję.
Nazwij polecenie testowe wprost. Wpisz je do reguły (na przykład npx vitest run), żeby agent nie zgadywał między npm test, jest a nieaktualnym skryptem.

Testing conventions for this repository:
- Framework: Vitest. Run the suite with `npx vitest run`; run one file with
  `npx vitest run <path>`.
- Tests live next to the code in __tests__/ folders and are named
  "should <behaviour> when <condition>".
- Unit tests never use real timers, random values, the network or a real
  database. Use vi.useFakeTimers(), fixed seeds and the factories in
  src/test-utils/factories.ts.
- A failing test is evidence, not an obstacle. Never weaken, delete or skip
  an assertion to make a test pass. If you think a test is wrong, stop and say
  which one and why.
- When asked to implement or fix code, do not edit files under __tests__/.
- After any change, run the affected test files, then `npx tsc --noEmit`
  and `npm run lint`, and report the results.

Reguła to instrukcja, a nie blokada. Żeby linia „nie edytuj testów” była egzekwowana, hooki Cursora mogą „obserwować, blokować albo modyfikować zachowanie” na etapach pętli agenta (cursor.com/docs/hooks, sprawdzone 28 sierpnia 2026). Strona Ochrona wyroczni pokazuje logikę blokady i kontrole CI, do których agent nie sięga.

Wygeneruj testy dla istniejącego kodu z zachowania, nie z implementacji

Najczęstsza porażka to zestaw, który opisuje kod zamiast wymagania. Gdy agent czyta payment-service.ts i pisze z niego testy, każdy test przechodzi przy pierwszym uruchomieniu, także na błędach. Podaj reguły sam i traktuj kod jak podejrzanego.

Write a Vitest suite for @src/services/payment-service.ts in
src/services/__tests__/payment-service.test.ts. Do not edit anything under src/
except that test file.

Treat the implementation as possibly wrong. Derive tests from these rules:
1. A payment amount is a positive integer in cents; zero, negative and
   fractional amounts are rejected with INVALID_AMOUNT.
2. A refund never exceeds the captured amount minus earlier refunds.
3. The same idempotency key never creates two charges.
4. A Stripe error or a database timeout leaves no partial payment row.
5. Only the payment's owner or an admin can refund it.

For every public function also cover: validation errors, external service
failures (mock the Stripe SDK, the database and the email service), boundary
values, and authorization errors. Use the factories in
@src/test-utils/factories.ts and the style of
@src/services/__tests__/user-service.test.ts.

Run the suite. List every test that fails on the current code and say whether
the test or the code looks wrong. Do not change a failing assertion.

Test, który tu nie przechodzi, to najcenniejszy wynik sesji: albo podana reguła jest błędna, albo właśnie znalazłeś błąd w kodzie. Rozstrzygnij, które z nich, zanim ktokolwiek cokolwiek zmieni.

Ten sam kształt promptu działa na innych warstwach. Wskaż plik z konwencjami, żeby agent użył twoich zapytań i matcherów zamiast wymyślać nowe.

Komponent React
Endpoint API w Node

Write Vitest + React Testing Library tests for @src/components/UserProfile.tsx.
Cover: renders the name and avatar from props, falls back to initials when
the avatar is missing, calls onEdit once when the edit button is clicked, and
disables the edit button while `saving` is true. Query by role and label,
never by class name. Follow @src/components/__tests__/Card.test.tsx.

Write supertest + Vitest tests for POST /api/users in @src/routes/users.ts.
Cover: 201 with a body containing `id` on valid input, 400 with an error
mentioning "email" on a malformed email, 409 on a duplicate email, and 401
without a session. Mock the database layer; do not hit a real database.

Testuj ścieżki asynchroniczne i błędów, które ukrywa pokrycie

Zielony test ścieżki szczęśliwej ukrywa ponowienie, timeout i odrzuconą obietnicę. Nazwij każdy przypadek i poproś o asercje liczby wywołań, bo „w końcu zwróciło dane” nie dowodzi, że logika ponowień zadziałała.

Write Vitest tests for fetchUserData(id) in @src/api/users.ts. Cover four cases:
1. Returns parsed data on a successful response.
2. Retries once and succeeds when the first call rejects with a network error.
3. Throws a typed FetchUserError after exhausting retries.
4. Does not retry on a 4xx response.
Stub fetch with vi.stubGlobal('fetch', vi.fn()) and assert the number of calls
in every case. Use fake timers for any backoff delay.

it('does not retry on a 4xx response', async () => {
  const fetchMock = vi.fn().mockResolvedValue({ ok: false, status: 404 });
  vi.stubGlobal('fetch', fetchMock);
  await expect(fetchUserData(1)).rejects.toThrow(FetchUserError);
  expect(fetchMock).toHaveBeenCalledOnce();
});

To linia toHaveBeenCalledOnce() łapie błąd. Bez niej klient, który trzy razy ponawia żądanie z odpowiedzią 404, nadal przechodzi.

Utrwal zachowanie legacy testami charakteryzacyjnymi

W kodzie, którego nikt w pełni nie rozumie, nie podasz jeszcze reguł. Testy charakteryzacyjne zapisują, co kod robi dziś, łącznie z zachowaniem, które wygląda na błędne, więc refaktor zmieniający zachowanie zapali test na czerwono. To warunek wstępny refaktoryzacji legacy w Cursorze; metodę niezależną od narzędzia opisuje strona o testach charakteryzacyjnych.

@src/services/legacy-pricing-engine.ts has no tests and complex business logic.
Write characterization tests in
src/services/__tests__/legacy-pricing-engine.test.ts. Do not edit the source.

1. List every exported function and the inputs that change its result.
2. For each, choose inputs that hit each branch: typical values, zero, negative,
   empty lists, very large numbers, and each discount tier boundary.
3. Run the real function and assert its actual output, even where it looks wrong.
4. Mark each surprising result with a comment starting "// SUSPECT:" and one
   sentence on why.
5. Run the suite twice. Every test must pass both times; if one does not, the
   code is nondeterministic and you must report where.

These tests capture behaviour so we can refactor safely. They do not judge it.

Przejrzyj komentarze SUSPECT: z kimś, kto zna domenę. Każdy z nich staje się albo zgłoszeniem prawdziwego błędu, albo udokumentowaną regułą. Nie pozwól agentowi „naprawiać” ich w trakcie refaktoru, który nastąpi potem.

Zamień błąd z produkcji najpierw w nieprzechodzący test

Poprawka bez nieprzechodzącego testu to zgadywanie. Każ agentowi odtworzyć błąd jako test, pokazać ci porażkę i dopiero wtedy naprawiać. Pełną pętlę odtwórz–zdiagnozuj–napraw opisuje debugowanie z AI w Cursorze.

Bug: orders with decimal quantities (for example 2.5 units of a product sold
by weight) make calculateOrderTotal in @src/services/order-service.ts return NaN.

Step 1. Write one test in src/services/__tests__/order-service.test.ts that
passes quantity 2.5 at a unit price of 400 cents and expects a total of 1000.
Run it and paste the failure output. Stop if it passes: then the bug is
somewhere else, and you should tell me what you checked.
Step 2. Fix the source. Do not change the test.
Step 3. Run the whole order-service test file and paste the result.

Wklejony wynik z kroku 1 jest dowodem. Test regresyjny, którego nikt nie widział na czerwono, niczego nie dowodzi o błędzie.

Zamykaj luki w pokryciu zamiast gonić procent

Procent pokrycia nie mierzy jakości: 100% pokrycia linii ze słabymi asercjami nadal przepuszcza błędy. Użyj raportu, żeby znaleźć gałęzie, których nikt nie testuje, a potem poproś o testy, które na ryzykownych gałęziach złapałyby regresję.

Run `npx vitest run --coverage src/auth`. For each file in src/auth, including files with no tests
(set coverage.include), list the uncovered branches and functions with line numbers. Rank them by risk: error
handling, security checks and money first, trivial getters last.

For the top five, write tests with realistic inputs in the existing test files,
following their style. Each test must assert an outcome that would change if
the branch were broken. Do not write a test that only executes a line.
Re-run coverage and show the before and after branch percentage per file.

File           | % Stmts | % Branch | % Funcs | % Lines
---------------|---------|----------|---------|--------
auth/login.ts  |   75.00 |    66.67 |  100.00 |   75.00
auth/reset.ts  |   45.00 |    33.33 |   66.67 |   45.00

W takim raporcie auth/reset.ts ma najcieńsze pokrycie gałęzi, więc przypadki brzegowe resetu hasła (wygasły token, już użyty token, nieznany e-mail) warto napisać jako pierwsze. Żeby --coverage działało, Vitest potrzebuje zainstalowanego dostawcy pokrycia, na przykład @vitest/coverage-v8. Ustaw coverage.include: ["src/**"] w konfiguracji Vitest, bo inaczej pliki bez żadnych testów w ogóle nie trafią do raportu. Jak zmierzyć, czy testy łapią błędy, a nie tylko dotykają linii, opisuje strona o sile wyroczni.

Zbuduj fabryki danych testowych raz

Obiekty wpisane w każdym teście rozjeżdżają się z prawdziwymi typami i wydłużają test ponad sprawdzane zachowanie. Poproś o fabryki raz i wpisz nazwę pliku do reguły testowej.

Create src/test-utils/factories.ts from the types in @src/types/.
Write createUser(overrides?), createOrder(overrides?) and
createPayment(overrides?). Each returns a complete, valid object, accepts a
partial object of overrides typed from the real type, links to its parent (an
order has a user, a payment has an order) and takes ids from one incrementing
counter, never Math.random(). Do not cast with `as`; let the compiler check
every default. Run `npx tsc --noEmit` and fix any type error in the factories.

Dobry wynik wygląda tak:

let seq = 0;
const nextId = () => ++seq;

export function createUser(overrides: Partial<User> = {}): User {
  const id = nextId();
  return { id: `user-${id}`, email: `test-${id}@example.com`, name: 'Test User', ...overrides };
}

Weryfikacją jest tu sprawdzanie typów: jeśli User dostanie nowe wymagane pole, fabryka przestanie się kompilować, zamiast po cichu tworzyć niepoprawne dane. Współdzielone fixture’y, seedowanie i zanonimizowane dane produkcyjne opisuje strona o zarządzaniu danymi testowymi.

Testy end-to-end z serwerem Playwright MCP

Przy ścieżkach przechodzących przez kilka stron serwer Playwright MCP (@playwright/mcp) pozwala agentowi sterować prawdziwą przeglądarką, więc może napisać test Playwright i od razu uruchomić go na lokalnej aplikacji. Dodaj go do pliku .cursor/mcp.json w projekcie; inne miejsca konfiguracji opisuje konfiguracja MCP.

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

--isolated trzyma profil przeglądarki w pamięci. README Playwrighta zaznacza, że trwałego profilu może naraz używać tylko jedna instancja przeglądarki, więc bez tej flagi równoległe agenty wchodzą sobie w drogę. Stary pakiet @modelcontextprotocol/server-puppeteer jest zarchiwizowany; używaj serwera Playwright. Jego schematy narzędzi i zrzuty stron zajmują kontekst, więc włączaj go do pracy nad UI, a nie w każdej sesji.

The app is running at http://localhost:3000 (started with `npm run dev`).
Using the Playwright MCP server, open /login and explore the form. Then write
tests/e2e/login.spec.ts with Playwright Test covering:
1. Valid credentials redirect to /dashboard.
2. Invalid credentials show an alert containing "Invalid credentials".
3. The "Forgot password" link navigates to /reset.
Use getByRole and getByLabel locators, never CSS selectors, and web-first
assertions such as await expect(page).toHaveURL(/\/dashboard/).
Run `npx playwright test tests/e2e/login.spec.ts` and fix failures in the test
setup only. If the app itself behaves wrongly, report it instead of adapting
the test.

test('shows an error for invalid credentials', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill('user@example.com');
  await page.getByLabel('Password').fill('wrong-password');
  await page.getByRole('button', { name: 'Sign in' }).click();
  await expect(page.getByRole('alert')).toContainText('Invalid credentials');
});

Dostępne lokatory przetrwają refaktory CSS, które psują selektory #id i .class, a do tego zawodzą, gdy kontrolka traci etykietę, czyli łapią błąd dostępności. W CI działa zacommitowany plik ze specyfikacją, a nie sesja przeglądarki agenta. Szerszą strategię E2E opisuje strona o automatyzacji testów end-to-end.

Zdiagnozuj niestabilny test powtarzanymi uruchomieniami

Test, który pada raz na dziesięć uruchomień, zabiera więcej czasu niż taki, który pada zawsze. Przewaga agenta polega na tym, że uruchomi test wiele razy z rzędu i się nie znudzi.

tests/e2e/checkout.spec.ts > "applies the discount" fails intermittently in CI
and usually passes locally.
1. Run `npx playwright test tests/e2e/checkout.spec.ts --repeat-each=25` and
   report how many runs fail, with the first failure output.
2. Log shared state at setup and teardown: database connections, timers,
   module-level variables, and network calls still in flight.
3. Name the source of nondeterminism (leaked state, an unawaited promise, a
   shared fixture, a real race) with the log lines that show it.
4. Propose a fix that removes the cause. A longer timeout or a retry is not a fix.
5. Apply it and re-run 25 times. Report the pass count.

Dla testów jednostkowych w Vitest zrób pętlę w terminalu: for i in $(seq 25); do npx vitest run src/cart/__tests__/cart.test.ts || echo FAIL; done. Poprawką jest zwykle izolacja, czyli hook sprzątający albo poczekanie na ustabilizowanie stanu, a nie dłuższy timeout. Wyścigi wymagające głębszego dochodzenia należą do strony o polowaniu na błędy.

Jak zweryfikować testy agenta bez czytania wszystkich?

Sprawdź, czy testy potrafią nie przejść i czy nikt ich nie nagiął do kodu. Wymagaj tych dowodów w każdym pull requeście, który dodaje testy, a kod testów czytaj tylko tam, gdzie czegoś brakuje albo coś zaskakuje.

Czerwony przed zielonym. Nowe testy nowego zachowania albo poprawki nie przechodzą na starym kodzie, a wynik porażki jest w pull requeście. Wyjątkiem są testy charakteryzacyjne: z założenia przechodzą.
Próba zepsucia. Dla każdego nowego testu agent robi najmniejszą zmianę, która powinna go zepsuć, pokazuje porażkę i cofa zmianę. Test, który zostaje zielony, jest ozdobą. Strona o sile wyroczni skaluje to do testów mutacyjnych całego zestawu.
Testy nietknięte podczas poprawki. git diff --stat commita z implementacją nie wymienia żadnego pliku testowego.
Żadnych pustych mocków. Prompt poniżej znajduje testy, które przeszłyby po usunięciu implementacji.
Bramki zielone w CI, nie tylko w raporcie agenta: testy, tsc --noEmit i linter. Podłącza je strona o CI/CD z Cursorem.

Review the tests added on this branch (`git diff main...HEAD --name-only -- '*.test.ts'`).
For each test, answer: would it still pass if the function under test returned
a hard-coded value, threw nothing, or were deleted and replaced by the mock?
List every test where the answer is yes, with the reason, and rewrite its
assertion to check real behaviour. Do not edit any file outside the test files.

Za te dowody odpowiada programista, który otworzył pull request. Recenzent, człowiek albo Bugbot, zatwierdza, gdy wszystkie punkty są spełnione. Uzasadnienie przeglądu dowodów zamiast diffów znajdziesz na stronie dowody, nie diffy.

Kiedy testy pisane przez agenta w Cursorze zawodzą

Objaw	Prawdopodobna przyczyna	Wyjście
Każdy nowy test przechodzi za pierwszym razem	Testy powstały z implementacji	Uruchom ponownie prompt „z zachowania” z podanymi regułami i `src/` tylko do odczytu
Nieprzechodzący test zazielenił się po zmianie pliku testowego (`toBe` zmienione na `toBeDefined`)	Agent osłabił asercję	Cofnij plik testowy, napisz „The test is correct; fix the implementation” i sprawdź `git diff --stat`
Testy przechodzą, a funkcja nie działa	Nadmiar mocków: testy sprawdzają mocka	Uruchom prompt o pustych mockach; zostaw co najmniej jeden test integracyjny albo E2E przechodzący przez prawdziwą granicę między komponentami
Pokrycie rośnie, a błędy dalej uciekają	Testy wykonują linie, ale nie sprawdzają wyników	Zrób próbę zepsucia na module, z którego uciekł błąd
Testy przechodzą lokalnie, padają w CI	Prawdziwe zegary, losowe wartości, współdzielony stan albo inne środowisko	Dodaj do reguły zakaz zegarów i losowości; odtwórz błąd poleceniem z CI i tymi samymi danymi
Agent uruchomił polecenie, które usunęło dane albo zrobiło push	Tryb uruchamiania, który przepuszcza każde polecenie	Przełącz się na tryb pytający przed poleceniami destrukcyjnymi i zdalnymi; przywróć stan z commita sprzed sesji
Testy Playwright od razu padają z błędami połączenia	Serwer deweloperski nie działa albo działa na innym porcie	Uruchom aplikację, wpisz dokładny URL do promptu i każ agentowi poczekać na odpowiedź serwera przed nawigacją
Niestabilny test „naprawiony” dłuższym timeoutem	Wyścig został ukryty, a nie usunięty	Poproś o przyczynę z dowodem w logach i 25 zaliczonych uruchomień z rzędu
Agent pisze kod na pięć funkcji zamiast zazielenić jeden test	Pętla jest za szeroka	Przerwij: „Stop. Make only the failing refund test pass, then run the suite.” Ciasna pętla daje lepszy kod niż jedna duża generacja
Jeden plik testowy przerasta kilkaset linii	Jeden plik na serwis zbiera wszystkie domeny	Poproś agenta o podział według zachowania (auth, zwroty, webhooki) i uruchom testy przed podziałem i po nim

Dokąd dalej z testowaniem w Cursorze

Test-driven development w Cursorze Najpierw test ze specyfikacji, który nie przechodzi, potem implementacja przez agenta Cursora.

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

Ochrona wyroczni Kontrole, których agent nie zmieni: zablokowane ścieżki testów, bramki w CI i ukryte scenariusze.

Code review w Cursorze Przegląd pull requestów z testami na podstawie dowodów przed merge'em.

Mapę sekcji znajdziesz w przeglądzie testowania i debugowania w Cursorze. Ten sam etap w innych narzędziach: testowanie z Claude Code i testowanie z Codeksem.