Awesome Testing
Request training offer

Markdown document

Podsumowanie sesji Codex

Lekcja 12: Plan zrównoleglenia pracy

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 l10 nad planem dalszej automatyzacji testów API.

Nie chodziło o dodanie nowych testów. Celem było przygotowanie planu, który jasno pokazuje:

  • jak podzielić dalszą pracę,
  • które endpointy można testować równolegle,
  • które elementy zależą od admina,
  • co blokuje testy koszyka i zamówień,
  • jak potraktować trudniejsze obszary: email, traffic correlation i Ollama streaming.

Finalnie aktywny plan został znacząco skrócony, historyczne szczegóły przeniesiono do osobnego pliku, a wynik pracy wypromowano do folderu l11.

Prompty użyte w Codex

Sesję rozpoczął prompt o aktualizację planu w l10:

work in l10 l10/api-test-plan.md Please update `api-test-plan.md` so that it no longer reads like a purely sequential checklist.

Użytkownik poprosił o sprawdzenie:

  • backendu w ../test-secure-backend,
  • mocka LLM w ../ollama-mock,
  • api-docs.json,
  • istniejących testów, klientów, fixture'ów i planu.

Po pierwszej odpowiedzi użytkownik doprecyzował praktyczny podział pracy:

So in practice what should we do next, one thread can work on endpoints not requiring admin access and the other requires admin access, right?

Następnie zwrócił uwagę, że tabela workstreamów jest za ciężka:

Maybe you can simplify our test plan, move exploration notes somewhere else and make it more obvious on first glance. Table is too complex for me

Po kolejnej iteracji użytkownik poprosił o jeszcze mocniejsze uproszczenie:

But move these historical stuff, update baseline and generally adopt _removal_ approach. I want to make simple doc which helps me. Not the lengthy one which I need to spend minutes navigating

Na końcu użytkownik poprosił, żeby z tej sesji zrobić materiał lekcyjny:

But apply the workflow, the lesson is about creating high-level plan, also describe my struggles to get it right in codex session summary

Co sprawdził Codex przed implementacją?

Codex sprawdził:

  • aktualny l10/api-test-plan.md,
  • istniejące testy, klientów, fixture'y i typy w l10,
  • api-docs.json,
  • backendowe kontrolery, serwisy, security, role, walidacje i dane testowe,
  • elementy związane z emailami, koszykiem, zamówieniami, produktami, traffic logs, QR i Ollama,
  • repozytorium ../ollama-mock, w tym streaming NDJSON, scenariusze i tool calling.

Codex potwierdził najważniejsze zależności:

  • admin fixture blokuje testy admin-only,
  • produkt testowy blokuje koszyk,
  • koszyk blokuje tworzenie zamówień,
  • zamówienie blokuje testy szczegółów, anulowania i statusów,
  • outbox/token blokuje solidne testy password reset,
  • streaming helper blokuje testy Ollama,
  • kontrolowany request blokuje testy traffic correlation.

Co zaimplementował Codex?

Najpierw Codex rozbudował l10/api-test-plan.md o bardzo szczegółowy model równoległej pracy:

  • workstreamy,
  • cele,
  • endpointy,
  • prerequisite'y,
  • blokery,
  • ryzyka,
  • pierwsze przypadki testowe,
  • potrzebne helpery,
  • komendy walidacyjne,
  • diagram Mermaid.

To było poprawne merytorycznie, ale za duże jako plan roboczy.

Po feedbacku użytkownika Codex uprościł plan:

  • dodał sekcję At A Glance,
  • opisał Thread A jako pracę bez admina,
  • opisał Thread B jako pracę wymagającą admina,
  • przeniósł notatki historyczne niżej.

To nadal nie było wystarczająco proste.

Po kolejnym feedbacku Codex zastosował podejście removal-first:

  • usunął dużą macierz endpointów z aktywnego planu,
  • usunął rozbudowane tabele workstreamów,
  • przeniósł stare notatki eksploracyjne i walidacje do api-test-plan-history.md,
  • zostawił w api-test-plan.md krótki plan roboczy.

Jakie korekty zostały zlecone po implementacji?

Korekty były najważniejszą częścią tej sesji.

Pierwsza wersja była zbyt sekwencyjna. Użytkownik chciał planu, który pokazuje równoległość, a nie tylko listę endpointów od góry do dołu.

Druga wersja poszła za daleko w drugą stronę. Powstała duża tabela workstreamów, która zawierała dużo prawdziwych informacji, ale była trudna do czytania. Użytkownik zauważył, że taki dokument nie pomaga na pierwszy rzut oka.

Trzecia korekta dotyczyła filozofii dokumentu. Użytkownik jasno wskazał, że plan ma być prosty, a nie kompletny za wszelką cenę. To doprowadziło do usunięcia nadmiaru i przeniesienia historii do osobnego pliku.

Najważniejszy feedback użytkownika:

I want to make simple doc which helps me.

Co wyszło w review?

Review pokazało, że plan techniczny może być formalnie poprawny, ale nadal nieużyteczny.

Najważniejsze wnioski:

  • "więcej informacji" nie zawsze oznacza "lepszy plan",
  • tabela może wyglądać profesjonalnie, ale utrudniać szybkie decyzje,
  • aktywny plan powinien być krótki,
  • historia i szczegóły powinny trafić do archiwum,
  • AI trzeba czasem prowadzić w stronę redukcji, nie rozbudowy,
  • wysoki poziom planowania oznacza wskazanie zależności i decyzji, a nie opisanie wszystkiego.

Wynik testów

Nie uruchamiano testów.

Powód: sesja dotyczyła wyłącznie dokumentacji i planowania. Nie dodawano ani nie zmieniano testów API.

Finalny efekt sesji

Powstały i zostały uporządkowane:

  • l11/api-test-plan.md jako krótki plan roboczy,
  • l11/api-test-plan-history.md jako archiwum historii,
  • opis Lekcji 12 w kanonicznym katalogu ait2api1s01l12-intro-do-zrownoleglenia-pracy,
  • codex-podsumowanie-sesji.md,
  • ZADANIE.md.

Najważniejszy efekt nie polega na liczbie nowych plików, tylko na zmianie jakości planu: dokument prowadzi kolejne kroki zamiast wymagać długiego czytania.