Podsumowanie sesji Codex

Zakres sesji

Sesja z 5 września 2026 dotyczyła testów czterech operacji inventory w l19. Punktem wyjścia było 170 testów i brak dedykowanej automatyzacji inwentarza. Najpierw sprawdzono backend oraz zachowanie API, następnie dodano testy, a na prośbę użytkownika przeprowadzono audyt ich stylu i podziału odpowiedzialności między testy backendowe a zdalne testy API.

Podsumowanie obejmuje pracę edukacyjną do końcowego review i zielonego wyniku 190 testów. Jest oparte na rzeczywistej sesji Codex. Trzy poniższe polecenia odpowiadają pracy pokazanej w filmie; późniejsze przygotowanie materiałów, przeniesienie checkpointu i produkcja wideo pozostają poza zakresem sesji edukacyjnej.

Prompty użyte w Codex

1. Rozpoznanie działania inventory

Work in l19, use english. Dobra, no to zostały nam tylko testy endpointa z inwentarzem. Jakbyś mógł mi sprawdzić w kodzie backendowym o co chodzi z tymi endpointami. Trener mówił, że to jest ilość produktów, które możemy sprzedać w ramach zamówień. Daj znać, czy to działa, czy są jakieś tutaj wyjątkowe rzeczy, na które powinienem zwrócić uwagę. No i powiedz mi, czy jesteś gotowy takie testy przygotować.

2. Implementacja testów

Ok implement it

3. Audyt, ograniczenie zakresu i dopasowanie stylu

Dobra, tylko takie, patrząc na te testy, mam wrażenie, że często są one trochę inne. Jest trochę testów sparametryzowanych, jakieś pętle for w środku, jakieś takie zagnieżdżone trochę testy. Zastanawiam się, czy nie moglibyśmy tego jakoś dostosować do tego, co było w projekcie, bo też zastanawiam się, czy takie 400, taka walidacja inputa powinna być pokrywana na tym poziomie czy nie. Także zrób mi proszę taki audyt, możesz zobaczyć, jak to jest testowane na poziomie backendu i może nieco ogranicz ilość tych testów. Może też nie rób takich dziwnych konstruktów jak expect, await, inventoryBody, API error response. Mam wrażenie, że wcześniej tak nie pisaliśmy, więc albo trzeba by te testy dostosować do reszty projektu, albo resztę testów zmienić. Także jeżeli uważasz, że możemy dostosować do reszty, to dostosuj, jeżeli uważasz, że resztę testów powinniśmy zmienić, to proszę uargumentuj mi to, bo ja nie jestem do tego przekonany.

Prompty zachowują oryginalny język i treść wiadomości. Instrukcje systemowe, kontekst narzędzi i późniejsze polecenia organizacyjne nie są promptami tej lekcji.

Co sprawdził Codex przed implementacją?

Codex przeczytał api-test-plan.md, repozytoryjny workflow testowania API, istniejące klienty HTTP, fixture i sąsiednie specy produktów oraz zamówień. W repozytorium backendowym przeanalizował AdminInventoryController, InventoryService, DTO, integrację koszyka, produktów i zamówień, obsługę wyjątków, blokady rekordów oraz migrację danych.

Pole availableQuantity odpowiada stockQuantity produktu. Dodanie produktu do koszyka sprawdza dostępność, ale nie rezerwuje zapasu. Dopiero utworzenie zamówienia zmniejsza stan, jeszcze przed płatnością. Anulowanie kwalifikującego się zamówienia przywraca zapas. Dla starych zamówień LEGACY_UNTRACKED backend nie wykonuje takiego przywracania.

Sprawdzono bieżące dokumenty /v3/api-docs obu środowisk. Repozytoryjny api-docs.json zawierał 42 operacje i nie opisywał inventory. Aktualny kontrakt obejmował 53 operacje na awesome.byst.re i 55 na aitesters.byst.re. Dodatkowe dwie operacje stagingu dotyczą lokalnego outboxa email.

Dostępne dane administratora działały na stagingu, ale logowanie nimi na awesome.byst.re zwróciło 422. Dlatego uwierzytelnione sprawdzenia inventory wykonano na aitesters.byst.re. Na środowisku kursowym potwierdzono kontrakt oraz 401 bez JWT, bez deklarowania zweryfikowanej zgodności ścieżek admina.

Co pokazała eksploracja API?

Przed automatyzacją wykonano osobne żądania curl na danych jednorazowych:

Działanie	Dostępny zapas
Utworzenie produktu	5
Korekta +3	8
Ponowienie identycznej korekty	8
Dodanie dwóch sztuk do koszyka	8
Utworzenie zamówienia na dwie sztuki	6
Anulowanie zamówienia	8

Korekta przyjmuje różnicę delta, uzasadnienie reason i UUID requestId. Powtórzenie identycznego żądania dla tego samego produktu zwraca tę samą zmianę z 201, zamiast ponownie aktualizować zapas. Ten sam requestId z inną treścią powoduje 409. Próba zejścia poniżej zera również zwraca 409, a delta równa zero powoduje 400. Historia pokazuje INITIAL_STOCK, ADMIN_ADJUSTMENT, ORDER_DEDUCTED i ORDER_RESTORED; zdarzenia zamówienia zawierają orderId.

Sprawdzono także uprawnienia, brakujący produkt, filtry i stronicowanie oraz wybrane granice walidacji. Wygenerowane dane zostały usunięte. Wykryto lukę w Swaggerze: prawidłowe odpowiedzi 400, 404 i 409 nie były opisane dla inventory. Powstał raport defektu kontraktu. Nie potraktowano poprawnych odrzuceń biznesowych jako błędnego działania API.

Co zaimplementował Codex?

Dodano httpclients/inventory-client.ts, typy w types/inventory.ts oraz fixtures/inventory-product.ts. Fixture tworzy własny produkt z pięcioma sztukami i unikalną nazwą/kategorią, a następnie usuwa go po teście. Test historii zamówienia wykorzystuje istniejący fixture disposableOrder.

Każda operacja ma osobny plik pod tests/api/admin/inventory:

Operacja	Plik	Finalna liczba testów
GET listy inventory	inventory.get.spec.ts	3
GET zapasu produktu	product-id.get.spec.ts	4
POST korekty zapasu	product-id-adjustments.post.spec.ts	8
GET historii produktu	product-id-movements.get.spec.ts	5

Testy admina działają w istniejącym projekcie admin-api na stagingu. Zachowano inicjalizację klientów w test.beforeEach, układ given/when/then, rosnące grupy statusów oraz sprawdzenia JSON i nagłówka no-store.

Jakie korekty zostały zlecone po implementacji?

Pierwsza wersja dodała 35 testów, pętle tworzące przypadki i helper inventoryBody, który łączył sprawdzanie odpowiedzi z parsowaniem JSON. Wszystkie testy przeszły, ale użytkownik zakwestionował ich czytelność oraz zgodność ze stylem kursu. Zielony wynik nie zamknął więc review.

Po audycie ograniczono zestaw do 20 jawnie zapisanych testów. Usunięto pętle parametryzujące przypadki, helpery inventoryBody/readState i zagnieżdżone konstrukcje typu expect(await ...). Zamiast nich każdy test osobno sprawdza status i nagłówki, przypisuje JSON do zmiennej body, a następnie wykonuje asercje. Pozostały istniejące helpery nagłówków i typ ApiErrorResponse używany już w innych specach. Nie było uzasadnienia do przebudowy reszty projektu pod nową abstrakcję.

Co wyszło w review?

Backendowe InventoryServiceTest sprawdzały już między innymi identyczne retry, konflikt requestId, niedozwolony ujemny zapas, dokładne zero, dokładne maksimum liczbowe oraz klasyfikacje zapasu. OrderServiceTest obejmowały przywrócenie zapasu tylko raz i obsługę starych zamówień. InventoryConcurrencyIT zawierały przypadki konkurencji o ostatnią sztukę, podwójnego checkoutu i rollbacku. Te testy zostały przeczytane, nie uruchomione w tej sesji.

Nie znaleziono dedykowanych testów backendowych dla każdej usuniętej walidacji DTO, odrzucenia przepełnienia i ograniczania stronicowania. Same adnotacje walidacyjne nie są pokryciem testowym. Te luki zapisano jako rekomendowane uzupełnienia backendu, zamiast twierdzić, że cała usunięta macierz była zbędna.

Pozostawiono jeden reprezentatywny test 400 dla delta=0. Na poziomie HTTP sprawdza on podłączenie walidacji i mapowanie błędu. Szczegółowe kombinacje pól oraz granice lepiej pokrywać szybkimi testami backendowymi. W zdalnym zestawie pozostały istotne przepływy: zapis stanu, retry bez duplikacji, konflikty, uprawnienia i integracja zamówienia z historią zapasu.

Wynik testów

Etap	Wynik
Pierwszy focused run inventory	35 passed, 26,6 s
Pierwszy pełny run l19	205 passed, 3,6 min
Focused run po uproszczeniu	20 passed, 17,3 s
Pełny run po uproszczeniu	190 passed, 3,4 min
Kontrola diffu	git diff --check bez błędów

Próba uruchomienia po zmianie uprawnień środowiska nie mogła rozwiązać nazwy hosta. Ponowienie z dostępem sieciowym zakończyło się sukcesem; problem nie był defektem API. Końcowy pełny run wykonano po finalnej korekcie kodu.

Finalny efekt sesji

Dodano 20 testów, zachowując wszystkie cztery operacje oraz 12 dokumentowanych ścieżek odpowiedzi inventory. Łączny zestaw ma 190 testów. Pokrycie operacji wzrosło z 48/55 do 52/55, a dokumentowanych odpowiedzi z 141/191 do 153/191. Zmniejszenie liczby przypadków po review nie obniżyło tych wskaźników, ale świadomie ograniczyło szczegółowość regresji na żywym środowisku.

Plan i audyt pokrycia w l20/api-test-plan.md dokumentuje aktualny zakres, ograniczenia i rekomendowane testy backendowe. Raport l20/api-coverage-report.html pokazuje te same wskaźniki. Wniosek z sesji: agent powinien dopasować nowy kod do projektu, a decyzję o liczbie testów uzasadniać ryzykiem i warstwą testowania.