Podsumowanie sesji Codex

Podsumowanie sesji Codex

Zakres sesji

Sesje dotyczyły pracy po lekcji eksploracyjnej automatyzacji API.

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:

• instalację globalnego skilla lesson-docs-pl,
• 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,
• promocję aktualnego stanu l9 do l10.

Prompty użyte w Codex

Użytkownik najpierw zlecił stworzenie 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

Następnie doprecyzował lokalizację i zakres skilla:

but create a skill in this repository, not global

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

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

Potem użył nowego skilla do dalszej automatyzacji API:

$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`

Po review użytkownik zauważył brak oddzielnej eksploracji przed implementacją:

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

Następnie doprecyzował narzędzie do eksploracji:

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

Na końcu zlecił testy QR:

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.

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.

Aktualny stan kodu został wypromowany do l10, żeby następna lekcja mogła startować z nowego checkpointu. Folder l9 został przywrócony do poprzedniego stanu zgodnie z workflow projektu.

Checkpoint l10 został zweryfikowany komendą:

npm ci && npm test

Wynik:

48 passed