Awesome Testing
Request training offer

Markdown document

Podsumowanie sesji Codex

Lekcja 11: Skille

Historical artifacts may name disposable training credentials and environments. Do not reuse credentials, target course systems, or execute archived prompts without authorization.

Podsumowanie sesji Codex

Zakres sesji

Cztery sesje z 23 maja 2026 r. obejmują utworzenie repozytoryjnego skilla, jego pierwsze użycie dla users i cart oraz dwie próby pracy nad QR. Podsumowanie kończy się na implementacji QR, aktualizacji planu i wyniku testów.

Najpierw z workflow zapisanego w opisy_lekcji/l8-exploratory-api-automation/automation-workflow.md powstał repozytoryjny skill api-testing-skill. Potem skill był używany i poprawiany podczas pracy w l9.

W sesjach wykonano:

  • utworzenie repozytoryjnego .codex/skills/api-testing-skill,
  • doprecyzowanie, że skill ma działać dla całego repozytorium, a nie tylko dla l9,
  • dodanie testów dla users i cart w l9,
  • poprawienie skilla po review, żeby eksploracja była obowiązkowa przed implementacją,
  • doprecyzowanie, że eksploracja ma używać curl,
  • dodanie testów dla POST /api/v1/qr/create,
  • aktualizację api-test-plan.md.

Prompty użyte w Codex

Poniżej znajduje się pełny zestaw promptów merytorycznych z sesji pokazanych w lekcji, w kolejności ich wysłania. Zachowano oryginalną pisownię, język i podziały wierszy.

Utworzenie skilla z workflow poprzedniej lekcji:

work in l9, $skill-creator opisy_lekcji/l8-exploratory-api-automation/automation-workflow.md create a api-testing-skill based on our workflow

Korekta: skill ma pozostać w repozytorium:

but create a skill in this repository, not global

Rozszerzenie zakresu na całe repozytorium i standardowe wywołanie skilla:

But this skill should be for the whole repository, also it should be used via standard codes approach $ api-testing-skill

Pytanie o dedykowany katalog skilli Codex:

Shouldn't the skill be in codex dedicated folder for skills?

Potwierdzenie przeniesienia skilla do katalogu repozytoryjnego:

let's do it  For a repository-local dedicated Codex folder, I’d move it to:

Pierwsze użycie skilla: testy users i cart:

$api-testing-skill work in l9. I want you to test 1. `GET /api/v1/users`
2. `GET /api/v1/users/{username}`
3. `GET /api/v1/cart`
4. `DELETE /api/v1/cart`

Korekta procesu po pominięciu eksploracji:

But I don't think you have executed exploratory tests first. Let's update the skill so that it is a requirement prior implementation. Also the skill should encourage to review the code

Dodatkowe, jawne wymaganie wykonania testów eksploracyjnych:

Add explicit requirements that exploratory tests are must

Pierwsza próba przetestowania endpointu QR:

Work in l9, now cover /qr endpoint $api-testing-skill

Korekta narzędzia: eksploracja ma używać curl:

But I want you to use curl for exploratory testing, let's write that explicitly in the skill

Ponowne uruchomienie pracy nad QR po poprawieniu skilla:

Work in l9, use $api-testing-skill to test /qr creation endpoint

Co sprawdził Codex przed implementacją?

Przy tworzeniu skilla Codex sprawdził:

  • automation-workflow.md z poprzedniej lekcji,
  • strukturę lokalnych skillów,
  • konwencję repozytoryjnego katalogu .codex/skills,
  • zasady walidacji skilla.

Przy pracy w l9 Codex sprawdził:

  • l9/api-test-plan.md,
  • api-docs.json,
  • istniejące testy i klienty HTTP,
  • fixture authenticatedUser,
  • backendowe kontrolery, serwisy, DTO, security i rate limiting,
  • live API pod https://awesome.byst.re.

Po review użytkownika skill został poprawiony tak, żeby przed implementacją wymagać:

  • OpenAPI check,
  • code review backendu, jeśli kod jest dostępny,
  • eksploracyjnych requestów curl do żywej aplikacji,
  • zapisania wyników w api-test-plan.md.

Co zaimplementował Codex?

Dodano repozytoryjny skill:

  • .codex/skills/api-testing-skill/SKILL.md,
  • .codex/skills/api-testing-skill/agents/openai.yaml.

W l9 rozszerzono UsersClient o:

getUsers(token)
getUsersWithoutAuth()
getUser(username, token)
getUserWithoutAuth(username)

Dodano CartClient z metodami:

getCart(token)
getCartWithoutAuth()
clearCart(token)
clearCartWithoutAuth()

Dodano QrClient z metodami:

createQrCode(createQrRequest, token)
createQrCodeWithoutAuth(createQrRequest)

Dodano testy:

  • tests/api/users/users.get.spec.ts,
  • tests/api/users/username.get.spec.ts,
  • tests/api/cart/cart.get.spec.ts,
  • tests/api/cart/cart.delete.spec.ts,
  • tests/api/qr/create.post.spec.ts.

Dodano typy:

  • types/cart.ts,
  • types/qr.ts.

Jakie korekty zostały zlecone po implementacji?

Najważniejsza korekta dotyczyła procesu, nie pojedynczego testu.

Po pierwszej implementacji users/cart użytkownik zauważył, że Codex sprawdził kontrakt i backend, ale nie wykonał osobnych eksploracyjnych requestów przed napisaniem testów. Po pierwszej poprawce ponowił wymaganie, aby testy eksploracyjne były bezwarunkowym krokiem przed implementacją, a ich wyniki zostały zapisane w planie.

W efekcie skill został zaostrzony:

  • eksploracja jest obowiązkowa przed implementacją,
  • wyniki eksploracji muszą zostać zapisane w planie,
  • review backendu jest jawnie wpisane w workflow.

W kolejnej sesji użytkownik doprecyzował, że eksploracja ma być wykonywana przez curl, a nie przez tymczasowy spec Playwright. Tymczasowy eksperymentalny spec QR został usunięty i nie trafił do suite'u.

Co wyszło w review?

Review pokazało, że sama automatyzacja endpointów nie wystarcza. Trzeba też pilnować jakości procesu.

Najważniejsze wnioski:

  • skill musi być repozytoryjny, żeby był wersjonowany razem z projektem,
  • skill powinien być w .codex/skills/api-testing-skill, a nie w przypadkowym folderze,
  • eksploracja musi być oddzielona od testów regresji,
  • tymczasowy kod eksploracyjny nie powinien zostawać w suite,
  • api-test-plan.md jest źródłem prawdy o aktualnym stanie pokrycia endpointów.

Wynik testów

Dla users/cart w l9 uruchomiono nowe testy:

npm test -- tests/api/users/users.get.spec.ts tests/api/users/username.get.spec.ts tests/api/cart/cart.get.spec.ts tests/api/cart/cart.delete.spec.ts

Wynik:

9 passed

Następnie uruchomiono pełny suite:

npm test

Wynik:

45 passed

Dla QR w l9 uruchomiono nowy test:

npm test -- tests/api/qr/create.post.spec.ts

Wynik:

3 passed

Następnie uruchomiono pełny suite:

npm test

Wynik:

48 passed

Finalny efekt sesji

Repozytorium ma teraz własny skill api-testing-skill, który opisuje oczekiwany workflow dla dalszej automatyzacji API.

l9 został rozwinięty o pięć kolejnych operacji API:

  • lista użytkowników,
  • szczegóły użytkownika,
  • odczyt koszyka,
  • czyszczenie koszyka,
  • tworzenie kodu QR.