Awesome Testing
Request training offer

Markdown document

Podsumowanie sesji Codex

Lekcja 1: Testy API dla endpointu signin

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

Ta sesja Codex dotyczyła przygotowania pierwszych testów API w projekcie Playwright dla endpointa logowania użytkownika.

W sesji wydarzyły się cztery główne rzeczy:

  1. Codex zebrał kontekst z dokumentacji projektu.
  2. Codex sprawdził endpoint logowania przez curl.
  3. Codex usunął startowe testy UI i dodał testy API.
  4. Po review poprawiono strukturę plików.

Prompt użyty w Codex

You are working in a new Playwright project, and the current working directory is `L1`.

Your task is to turn this project into a clean, maintainable API testing setup for the user sign-in / login endpoint.

Requirements:

The project documentation is already present in the repository. Use it as the source of truth.
Before writing tests, first explore the login endpoint with curl:
find the relevant endpoint details in the project documentation,
call it with curl,
verify that it is reachable,
verify that the actual behaviour matches the documentation,
inspect request/response shape, headers, status codes, and any useful edge cases.
Use these valid credentials for successful login testing:
username: slaweczek
password: slaweczek

Implementation expectations:

Remove the default / starter UI tests that are currently in the project and are no longer needed.
Create API tests for the login endpoint using Playwright.
Do not put everything in one file.
Use good Playwright and test automation practices:
clear project structure,
reusable helpers/utils where appropriate,
an HTTP/API client abstraction if useful,
readable naming,
maintainable and extensible code,
sensible assertions,
avoid duplication.
Keep the codebase high quality and production-like.

Test design requirements:

Organise the test cases by HTTP response code in ascending order.
Start from the lower successful / client response codes and keep them ordered numerically, for example:
200
400
401
Cover the realistic scenarios supported by the endpoint and documentation.
Include positive and negative cases where appropriate.

Execution requirements:

After implementing the tests, run them.
Fix any issues needed so that the tests pass successfully.
Make sure the final solution is working, not just generated.

Deliverables:

Update the project files as needed.
Ensure the resulting structure is clean and easy to extend with more API endpoints later.
At the end, provide a concise summary of:
what was changed,
which files were added/updated/removed,
what curl exploration confirmed,
and the final test run result.

Korekta inicjalizacji klienta po pierwszym review:

AuthClient can probably be initialized in before_each.

Przeniesienie klientów HTTP do osobnego katalogu:

Move HTTP clients to L1 folder, rename to HTTP clients.

Uproszczenie położenia kodu pomocniczego:

Maybe move support to root L1 folder.

Co wynika z jakości prompta?

W tej sesji dobrze widać, że jakość polecenia ma bardzo duże znaczenie już na samym początku pracy z agentem.

Autor lekcji dyktował wymagania głosowo, a potem wkleił gotowy prompt do Codex. To wygodne, ale wymaga precyzji, bo agent bardzo często kopiuje:

  • kolejność kroków,
  • poziom szczegółowości,
  • standard jakości,
  • sposób organizacji pracy.

Samo dyktowanie daje też konkretne korzyści:

  • jest szybsze niż ręczne pisanie,
  • łatwiej pozwala przekazać bogatszy kontekst,
  • pomaga uchwycić naturalny tok myślenia: cel, ograniczenia, wyjątki i priorytety.

To ważne, bo agent kodujący działa lepiej wtedy, gdy dostaje nie tylko sam cel, ale też logikę dojścia do rozwiązania.

Jeżeli prompt mówi:

  • najpierw przeczytaj dokumentację,
  • potem sprawdź endpoint przez curl,
  • potem usuń starterowe testy UI,
  • a dopiero potem wygeneruj kod,

to agent ma dużą tendencję do wykonania właśnie takiego workflow.

LLM jest tu też bardzo dobrym narzędziem pośrednim. Z surowego, mówionego opisu potrafi wygenerować znacznie lepszy prompt dla agenta: uporządkować wymagania, doprecyzować ograniczenia, nazwać oczekiwane deliverables i zamienić ogólną intencję w instrukcję operacyjną.

Co sprawdził Codex przed implementacją?

Codex najpierw zebrał kontekst z projektu:

  • przeczytał README.md,
  • odczytał api-docs.json,
  • sprawdził strukturę projektu Playwright,
  • znalazł endpoint POST /api/v1/users/signin.

Następnie wykonał eksplorację endpointa przez curl.

Co potwierdził curl?

Codex potwierdził, że endpoint:

POST https://awesome.byst.re/api/v1/users/signin

działa dla poprawnych danych logowania:

username: slaweczek
password: slaweczek

Najważniejsze obserwacje z eksploracji:

  • poprawne dane zwracają 200,
  • odpowiedź 200 zawiera dane sesji, token, refresh token, username, dane profilu i role,
  • zbyt krótkie pola zwracają 400 z komunikatami walidacyjnymi,
  • niepoprawne, ale poprawnie zbudowane dane logowania zwracają 422,
  • odpowiedzi są zwracane jako JSON,
  • odpowiedzi mają nagłówki zabezpieczające przed cache'owaniem.

Codex zauważył też, że część nietypowych requestów może zwracać 401, ale finalne testy oparł na scenariuszach zgodnych z dokumentacją endpointa.

Co zaimplementował Codex?

Codex usunął startowe testy UI i przygotował strukturę testów API:

  • playwright.config.ts - konfiguracja Playwright dla testów API,
  • httpclients/auth-client.ts - klient HTTP dla logowania,
  • support/config.ts - konfiguracja i dane logowania,
  • support/assertions/http.ts - wspólne asercje HTTP,
  • types/auth.ts - typy requestów i response'ów,
  • tests/api/users/signin.spec.ts - testy endpointa signin.

Jakie testy powstały?

Testy zostały uporządkowane według kodów odpowiedzi:

200
400
422

Zakres testów:

  • 200 - poprawne logowanie zwraca dane sesji,
  • 400 - zbyt krótkie dane wejściowe zwracają błędy walidacji,
  • 422 - niepoprawne dane logowania zwracają błąd uwierzytelnienia.

Co poprawiono po pierwszej wersji?

Po pierwszej wersji kodu wykonano review i doprecyzowano strukturę:

  • AuthClient został inicjalizowany w beforeEach,
  • klient HTTP został przeniesiony do folderu httpclients,
  • kod pomocniczy został przeniesiony do folderu support,
  • testy zostały zostawione w katalogu tests/api/users.

Ten etap review jest szczególnie ważny, bo pierwsza wersja testów bardzo łatwo staje się wzorcem dla kolejnych zadań. Gdy później agent dostaje następny endpoint do przetestowania, czyta istniejący kod i traktuje go jako przykład tego, jak projekt powinien wyglądać.

Właśnie tutaj dobrze działa analogia do few-shot promptingu. Nie chodzi o samo dyktowanie, tylko o to, że reviewed kod z pierwszej iteracji działa jak zestaw przykładów dla następnych agentów. Jeżeli zostawimy słabą strukturę, duplikację i przypadkowe decyzje, agent będzie to powielał. Jeżeli dopracujemy pierwszy slice projektu, to kolejne generacje zwykle podążają za tym standardem.

Wynik testów

Po implementacji Codex uruchomił testy i doprowadził je do stanu przechodzącego.

Finalny efekt sesji

Po tej sesji projekt miał działające testy API dla logowania:

  • startowe testy UI zostały usunięte,
  • endpoint signin został wcześniej sprawdzony przez curl,
  • kod testów został podzielony na klienta API, konfigurację, typy, asercje i specyfikację,
  • testy były uporządkowane według kodów odpowiedzi.

Dodatkowy wniosek z tej lekcji:

  • dyktowanie przyspiesza pracę,
  • pomaga przekazać bogatszy kontekst niż krótka komenda tekstowa,
  • LLM może zamienić taki surowy opis w lepszy prompt dla agenta,
  • reviewed kod z pierwszej iteracji staje się przykładem dla kolejnych agentów,
  • ale nadal trzeba pilnować jakości i precyzji,
  • bo agent bardzo często kopiuje sposób sformułowania prompta do kodu i do całego workflow.