Awesome Testing
Request training offer

Markdown document

Podsumowanie sesji Codex

Lekcja 10: Zadanie 2 - rozwiązanie

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

Sesja dotyczyła pracy w folderze l8 i pokrycia testami ośmiu kolejnych endpointów API:

  • GET /api/v1/traffic/info,
  • GET /api/v1/traffic/logs,
  • GET /api/v1/products,
  • GET /api/v1/products/{id},
  • GET /api/v1/users/chat-system-prompt,
  • PUT /api/v1/users/chat-system-prompt,
  • GET /api/v1/users/tool-system-prompt,
  • PUT /api/v1/users/tool-system-prompt.

Użytkownik poprosił, żeby przed implementacją sprawdzić, czy w endpointach nie ma czegoś nietypowego, i wykonać eksploracyjne testy ręczne.

W sesji powstały:

  • eksploracyjne notatki w api-test-plan.md,
  • plan implementacji automatyzacji,
  • testy dla ośmiu endpointów,
  • klienci TrafficClient i ProductsClient,
  • metody promptów w UsersClient,
  • typy DTO dla traffic, products i promptów,
  • bug report dla zespołu developerskiego,
  • opis workflow pracy: eksploracja, plan, implementacja, review.

Prompty użyte w Codex

Pierwszy prompt uruchomił eksplorację endpointów przed automatyzacją:

Work in l8 folder. Check api test plan. I wish to cover 8 new endpoints. | 3 | `GET /api/v1/traffic/info` | 1 | Public, deterministic response. |
| 4 | `GET /api/v1/traffic/logs` | 1 | Public paginated read; keep assertions structural. |
| 5 | `GET /api/v1/products` | 2 | Authenticated read-only endpoint. |
| 6 | `GET /api/v1/products/{id}` | 2 | Authenticated read plus straightforward `404`. |
| 7 | `GET /api/v1/users/chat-system-prompt` | 2 | Authenticated current-user read. |
| 8 | `PUT /api/v1/users/chat-system-prompt` | 2 | Authenticated current-user update with simple payload. |
| 9 | `GET /api/v1/users/tool-system-prompt` | 2 | Same pattern as chat prompt. |
| 10 | `PUT /api/v1/users/tool-system-prompt` | 2 | Same pattern as chat prompt update. |. Before we start I'd like you to check whether there is something unusual in them and I'd like you to perform exploratory tests first. Do they work as designed?

Następnie użytkownik poprosił o plan przed generowaniem kodu:

Ok, I would ask you to prepare a ticket for Jira later but let's now create implementation plan towards automation. I'd like to read it first before code generation

Po zaakceptowaniu planu użytkownik zlecił implementację:

Ok, create the tests now. If you wish you can spawn subagents to parallelise work

Na końcu użytkownik poprosił o bug report i zapis workflow:

Ok now do two things. Create bug report for development team (use testing best practices, like steps to reproduce, etc.) and save our workflow, mention that we start with exploratory test, then exploration and implementation plan, then we implement and review/improve the code

Co sprawdził Codex przed implementacją?

Codex sprawdził:

  • istniejący api-test-plan.md,
  • api-docs.json,
  • schematy OpenAPI dla traffic, products i promptów,
  • istniejące testy i konwencje z l8,
  • klientów AuthClient i UsersClient,
  • fixture authenticatedUser,
  • rzeczywiste zachowanie endpointów na żywej aplikacji.

W eksploracji potwierdzono, że:

  • GET /api/v1/traffic/info zwraca publiczny, stabilny obiekt,
  • GET /api/v1/traffic/logs zwraca dynamiczne, paginowane logi,
  • endpointy produktowe wymagają JWT,
  • GET /api/v1/products/{id} zwraca 404 dla brakującego produktu,
  • endpointy promptów wymagają JWT,
  • poprawne PUT prompta zapisuje wartość,
  • prompt dłuższy niż 5000 znaków zwraca 400,
  • błędne pole w body prompta zwraca 200 i zapisuje null.

Ostatnie zachowanie uznano za bug/quirk, którego nie należy utrwalać w testach automatycznych.

Co zaimplementował Codex?

Dodano TrafficClient z metodami:

getInfo()
getLogs(params)

Dodano ProductsClient z metodami:

getProducts(token)
getProductsWithoutAuth()
getProduct(id, token)
getProductWithoutAuth(id)

Rozszerzono UsersClient o metody:

getChatSystemPrompt(token)
getChatSystemPromptWithoutAuth()
updateChatSystemPrompt(prompt, token)
updateChatSystemPromptWithoutAuth(prompt)
getToolSystemPrompt(token)
getToolSystemPromptWithoutAuth()
updateToolSystemPrompt(prompt, token)
updateToolSystemPromptWithoutAuth(prompt)

Dodano typy:

  • TrafficInfoResponse,
  • TrafficLogsResponse,
  • TrafficLogEntry,
  • ProductResponse,
  • ChatSystemPromptResponse,
  • ToolSystemPromptResponse,
  • walidacyjne typy błędów promptów.

Dodano testy:

  • tests/api/traffic/info.spec.ts,
  • tests/api/traffic/logs.spec.ts,
  • tests/api/products/products.get.spec.ts,
  • tests/api/products/id.get.spec.ts,
  • tests/api/users/chat-system-prompt.get.spec.ts,
  • tests/api/users/chat-system-prompt.put.spec.ts,
  • tests/api/users/tool-system-prompt.get.spec.ts,
  • tests/api/users/tool-system-prompt.put.spec.ts.

Jakie korekty zostały zlecone po implementacji?

Po implementacji użytkownik poprosił o dwa artefakty:

  • bug report dla zespołu developerskiego,
  • zapis workflow użytego w tej sesji.

Codex przygotował bug report opisujący problem z błędnym polem w requestach PUT promptów oraz dokument workflow:

exploratory test -> exploration findings -> implementation plan -> implementation -> review/improvement

Te artefakty zostały później przeniesione do materiałów lekcyjnych, żeby nie zaśmiecały folderu z kodem testów.

Co wyszło w review?

Najważniejszy wniosek dotyczył granicy między eksploracją a automatyzacją.

Nie każde zaobserwowane zachowanie powinno zostać testem regresji. Jeśli endpoint zachowuje się podejrzanie, najpierw trzeba zdecydować, czy to:

  • oczekiwany kontrakt,
  • luka w dokumentacji,
  • błąd produktu,
  • zachowanie tymczasowe.

W tej sesji zachowanie PUT promptów z błędnym polem wyglądało jak błąd produktu, więc zostało opisane w bug reporcie, a nie zakodowane jako oczekiwany wynik testu.

Wynik testów

Najpierw uruchomiono nowe testy:

npx playwright test tests/api/traffic/info.spec.ts tests/api/traffic/logs.spec.ts tests/api/products/products.get.spec.ts tests/api/products/id.get.spec.ts tests/api/users/chat-system-prompt.get.spec.ts tests/api/users/chat-system-prompt.put.spec.ts tests/api/users/tool-system-prompt.get.spec.ts tests/api/users/tool-system-prompt.put.spec.ts

Wynik:

17 passed

Następnie uruchomiono pełny zestaw:

npm test

Wynik:

36 passed

Podczas uruchomień pojawiał się ostrzegawczy komunikat Node o NO_COLOR i FORCE_COLOR, ale nie wpływał na wynik testów.

Finalny efekt sesji

l8 ma pokryte endpointy:

  • traffic info,
  • traffic logs,
  • products list,
  • product by id,
  • chat system prompt GET/PUT,
  • tool system prompt GET/PUT.

Plan API został zaktualizowany i wskazuje kolejne sugerowane endpointy:

  • GET /api/v1/users,
  • GET /api/v1/users/{username},
  • GET /api/v1/cart,
  • DELETE /api/v1/cart.

Stan kodu z l8 został przygotowany do skopiowania do l9, żeby następna lekcja mogła startować z aktualnego checkpointu.