Przepływy pracy oparte na zachowaniu

Funkcja checkoutu przechodzi każdy test jednostkowy i wciąż dostarcza nie to: kryteria akceptacji żyły w zgłoszeniu Jira, którego nikt nie podał agentowi, więc AI optymalizowało pod “testy są zielone” zamiast pod “użytkownik faktycznie może to kupić”. Behavior-Driven Development zamyka tę lukę, czyniąc wykonywalną specyfikację — scenariusze Gherkin — źródłem prawdy, pod które agent koduje.

Asystenci AI są niezwykle dobrymi partnerami w BDD, bo cała metodologia jest “najpierw język naturalny”. Ty definiujesz zachowanie w Given/When/Then, agent generuje definicje kroków i implementację, a runner BDD jest obiektywną bramką, która mówi wam obojgu, czy zachowanie jest prawdziwe.

Co z tego wyniesiesz

Powtarzalną pętlę, która zamienia plik .feature w definicje kroków, implementację i przechodzący pakiet.
Gotowe prompty do generowania definicji kroków Cucumber.js, implementacji pod kontrakt i doprowadzenia pakietu do zieleni.
Ścieżki wykonania w trzech narzędziach (Cursor, Claude Code, Codex) do przekazania agentowi pliku .feature i uruchomienia runnera.
Tryby porażki, które po cichu pokonują BDD sterowane AI — agent edytujący specyfikację, by testy przeszły, niestabilne kroki asynchroniczne — i jak je odgrodzić.

Cykl BDD wspomagany przez AI

Przepływ pracy BDD z asystentem AI podąża za jasnym, współpracującym cyklem, który zapewnia, że finalny produkt odpowiada pożądanemu doświadczeniu użytkownika.

1. Zdefiniuj zachowanie (Given/When/Then)

Zaczynasz od napisania specyfikacji funkcji używając składni Gherkin (Given, When, Then). Opisuje ona scenariusz użytkownika prostym językiem. Możesz nawet współpracować z AI, by udoskonalić te historie użytkowników.

2. Wygeneruj definicje kroków

Przekazujesz plik .feature do AI i prosisz o wygenerowanie odpowiadających mu plików definicji kroków dla twojego frameworka testowego (np. Cucumber, Behat, SpecFlow). Początkowo będą one puste lub zawierać kod zastępczy.

3. Zaimplementuj funkcję

Mając już kontrakt behawioralny, instruujesz AI, by napisało kod aplikacji niezbędny do spełnienia scenariuszy w pliku .feature.

4. Uruchom, zweryfikuj i refaktoryzuj

Na koniec AI uruchamia testy BDD. Analizuje wszelkie niepowodzenia i iteruje nad kodem aplikacji, aż wszystkie scenariusze przejdą pomyślnie. Tworzy to ciasną pętlę sprzężenia zwrotnego napędzaną bezpośrednio przez zachowanie widoczne dla użytkownika.

Praktyczny przepływ pracy BDD

Przejdźmy przez prawdziwą regułę od początku do końca: “Dodaj do koszyka” ograniczone stanem magazynu dla witryny sklepowej w Next.js, testowane Cucumber.js + Playwright na działającej aplikacji. Ciekawe zachowanie to nie “przycisk działa” — to granica: nie możesz dodać więcej sztuk, niż jest na stanie. Ten edge case to dokładnie to, co ginie, gdy kryteria żyją w zgłoszeniu, a nie w specyfikacji.

Krok 1 — Napisz plik funkcji Gherkin

Zakoduj regułę, łącznie ze ścieżką porażki, w features/cart.feature:

Feature: Stock-limited cart
  As a shopper
  I want the cart to respect available stock
  So that I can't order items the warehouse doesn't have

  Background:
    Given the product "Super Widget" has 2 units in stock

  Scenario: Adding within the stock limit
    Given I am on the product page for "Super Widget"
    When I add 2 of "Super Widget" to my cart
    Then my cart should contain 2 "Super Widget"

  Scenario: Blocked from exceeding the stock limit
    Given I am on the product page for "Super Widget"
    When I add 2 of "Super Widget" to my cart
    And I try to add 1 more "Super Widget"
    Then I should see "Only 2 in stock"
    And my cart should contain 2 "Super Widget"

Drugi scenariusz to cały sens: to zachowanie, które testy jednostkowe zwykle pomijają i którego AI inaczej nigdy by nie wiedziało, że ma zbudować.

Krok 2 — Wygeneruj definicje kroków

Przekaż agentowi plik .feature i poproś o typowane definicje kroków podpięte do Playwright. Sposób odwołania do pliku różni się per narzędzie — @-wzmianki to idiom Cursora, nie Claude Code czy Codeksa.

Read features/cart.feature. Generate Cucumber.js step definitions in
features/steps/cart.steps.ts using @cucumber/cucumber and Playwright
(@playwright/test) to drive the running Next.js app at http://localhost:3000.

- One step function per unique Given/When/Then; share the Playwright `page`
  via the World, not module globals.
- Implement the "N units in stock" Background by seeding via the test API
  route POST /api/test/seed, not by mocking inside the step.
- Leave a `// TODO: assert` only where the selector is genuinely unknown;
  everywhere else, write the real Playwright assertion.
- Do NOT edit cart.feature.

W trybie agenta wspomnij specyfikację przez @features/cart.feature, by była przypięta w kontekście, potem wklej prompt. Przejrzyj wygenerowane cart.steps.ts w widoku diffa przed akceptacją — inline’owy diff Cursora ułatwia wyłapanie kroku, który po cichu stubuje asercję.

Wskaż ścieżkę zwykłym tekstem (Read features/cart.feature) — w terminalu nie ma udogodnienia @-wzmianki. Claude Code wczytuje plik własnymi narzędziami i potrafi w jednej turze postawić katalog kroków. Trzymaj to w tej samej sesji, by pamiętał konfigurację World, gdy przejdziesz do implementacji.

Uruchom w powierzchni IDE lub CLI na worktree, który ma plik funkcji. Wskaż ścieżkę w prompcie; Codex sam otwiera plik. Na czystym worktree możesz pozwolić mu napisać katalog kroków i konfigurację cucumber.js w jednym tasku.

Krok 3 — Implementuj pod kontrakt

Mając już wykonywalny kontrakt, każ agentowi zbudować implementację — store koszyka, strażnika stanu magazynu i inline’owy błąd — aż scenariusze będą mogły przejść.

Using features/cart.feature as the contract, implement the stock-limited
cart in the Next.js app:
- a cart store (Zustand) with an addItem(id, qty) that rejects quantities
  beyond available stock and returns a typed result;
- the "Only N in stock" message rendered inline on the product page;
- the POST /api/test/seed route used by the Background.
Touch only app/, components/, lib/cart/, and the test seed route.
Do not modify cart.feature or weaken any assertion in cart.steps.ts.

Nazwanie stacku (store Zustand, typowany wynik, inline’owy komunikat) powstrzymuje agenta przed wymyślaniem globalnej szyny zdarzeń albo biblioteki toastów, której nie używasz. Bariera “nie modyfikuj specyfikacji ani nie osłabiaj asercji” to pojedyncza najważniejsza linijka w BDD-z-AI — patrz “Kiedy to się psuje” poniżej.

Krok 4 — Uruchom pakiet i iteruj

Teraz pozwól agentowi zamknąć pętlę na prawdziwym wyjściu. To tutaj trzy narzędzia naprawdę się rozchodzą: kto uruchamia komendę.

Run `npm run test:bdd` (cucumber-js). For each failing scenario, read the
Cucumber output, identify the failing step, and fix the application code or
selector — never the .feature file. Re-run until all scenarios pass. If a
step fails because the behavior is genuinely ambiguous, stop and ask me
instead of guessing.

Tryb agenta może uruchomić npm run test:bdd w zintegrowanym terminalu i odczytać wyjście, ale przy długiej pętli red-to-green lepszy jest agent w tle: przekaż mu pakiet i pozwól iterować, gdy ty pracujesz dalej, potem przejrzyj końcowy diff.

To najmocniejsza powierzchnia Claude Code: uruchamia pakiet narzędziem Bash, parsuje czytelny dla człowieka raport Cucumbera i iteruje w sesji. Ogranicz go przez --allowedTools (np. Edit, Bash), by mógł uruchamiać testy i łatać kod, ale ty zostajesz przy sterach reszty.

Uruchom pakiet z CLI/IDE Codeksa na worktree albo zrzuć go do Codex Cloud na dłuższy nienadzorowany przebieg red-to-green i przejrzyj wynikowy PR. Trzymaj zatwierdzenia na on-request (--ask-for-approval on-request), by pauzował przed czymkolwiek poza uruchomieniem pakietu i edycją kodu aplikacji.

Kiedy to się psuje

BDD-z-AI zawodzi na konkretne, rozpoznawalne sposoby. Wypatruj tych.

Agent edytuje specyfikację, by testy przeszły. To grzech kardynalny — zamienia kontrakt w pieczątkę. Trzymaj pliki *.feature poza zakresem zapisu agenta (albo w chronionej ścieżce) i upewnij się w review, że diff ich nie dotyka. Linijka-bariera w każdym powyższym prompcie istnieje właśnie dla tego.
Osłabia asercje zamiast naprawiać kod. Subtelniejsze niż edycja pliku funkcji: zmienia should contain 2 na should contain at least 1 albo zakomentowuje sprawdzenie “Only 2 in stock”. Diffuj definicje kroków, nie tylko kod aplikacji.
Niestabilne kroki asynchroniczne. Kroki Cucumber.js + Playwright, które ścigają się z UI, przechodzą lokalnie i padają w CI. Pchaj agenta ku auto-czekającym locatorom Playwright i asercjom web-first (await expect(locator).toHaveText(...)) zamiast sztywnych czekań setTimeout/page.waitForTimeout.
Niejednoznaczny Gherkin produkuje niejednoznaczny kod. “Then the cart should be correct” nie daje agentowi nic do podpięcia. Jeśli krok nie ma obserwowalnej asercji, to specyfikacja jest błędem — dociśnij Gherkin, zanim obwinisz implementację.
Rozrost definicji kroków. Agent pisze niemal-duplikat kroku dla każdego sformułowania. Okresowo proś go o konsolidację kroków i wyciągnięcie wspólnego setupu do World albo Background.

Co dalej

Test-Driven Development — pętla red/green na poziomie jednostek, która łączy się z tymi scenariuszami na poziomie zachowania.
Testy end-to-end — wejdź głębiej w sterowanie Playwright agentem AI, w tym selektory i kontrolę niestabilności.
PRD → Plan → Todo — zamień specyfikację produktu w kryteria akceptacji, które kodują twoje pliki .feature.