Podsumowanie sesji Codex

Zakres sesji

Sesja dotyczyła przygotowania niezależnej infrastruktury testów API dla ścieżki administracyjnej. Istniejące testy użytkownika miały nadal działać na https://awesome.byst.re, natomiast testy admina miały korzystać z codziennie resetowanego środowiska https://aitesters.byst.re.

W sesji użyto danych administratora: login admin, hasło LocalDemoAdmin123!. W projekcie testowym dane te zostały zapisane w lokalnym, ignorowanym pliku .env.

Celem było:

rozdzielenie testów na dwa projekty Playwright uruchamiane razem lub osobno,
przygotowanie konfiguracji i fixture'a zalogowanego admina,
umożliwienie bezpiecznej pracy równoległej,
dodanie pierwszych testów endpointów administracyjnych,
potwierdzenie kontraktu przez eksplorację live API.

Prompty użyte w Codex

Sesję rozpoczęła prośba o przygotowanie adminowej części planu testów. Użytkownik wskazał osobny URL stagingowy, dane admina przekazane na zrzucie ekranu, obsługę wielu tokenów JWT dla jednego użytkownika oraz wymaganie równoległego działania obu strumieni testów:

Pracuj w folderze L12, odpowiadaj mi po angielsku, ja będę mówił po polsku.
W API test plan mamy dwa wątki: admina i nie-admina. Przygotuj infrastrukturę
i fixture'y dla wątku adminowego. Testy adminowe mają działać na
https://aitesters.byst.re, a pozostałe na https://awesome.byst.re.
Dane admina są na zrzucie ekranu: login admin, hasło LocalDemoAdmin123!.
Potraktuj hasło jak sekret i umieść je w .env, zaktualizuj .env.example.
Dodaj proste testy endpointów adminowych. Testy
adminowe mają działać równolegle ze sobą i z obecnymi testami. Zrób discovery
i przygotuj projekt do dalszej pracy nad adminem.

Następnie użytkownik doprecyzował sposób uruchamiania dwóch suite'ów:

so we have 2 different test suites, api and api admin, right? maybe we should add such scripts to package.json

Po pierwszej implementacji poprosił o generator danych produktu oparty na Fakerze:

Use faker to create productGenerator instead, same like for users

Co sprawdził Codex przed implementacją?

Codex przeczytał aktualny api-test-plan.md, konfigurację Playwright, istniejące fixture'y, klientów HTTP, generatory danych i typy DTO. Sprawdził również api-docs.json oraz kod backendu, aby potwierdzić role, statusy odpowiedzi i możliwość posiadania wielu aktywnych tokenów JWT przez jednego użytkownika.

Eksploracja live API na https://aitesters.byst.re potwierdziła:

poprawne logowanie admina zwraca 200 i rolę ROLE_ADMIN,
niepoprawne, ale zgodne ze schematem dane logowania zwracają 422,
GET /api/v1/users/me działa z tokenem admina,
admin może utworzyć produkt przez POST /api/v1/products i otrzymuje 201,
błędne dane produktu zwracają 400,
brak JWT zwraca 401,
użytkownik z rolą ROLE_CLIENT otrzymuje 403,
tymczasowy produkt i użytkownik mogą zostać usunięci podczas cleanupu,
refresh token na stagingu jest nieprzezroczystym ciągiem, a nie UUID jak w dotychczasowym fixture użytkownika.

Codex uruchomił też istniejący suite przed zmianami. Bazowy wynik wynosił 59 zaliczonych testów.

Co zaimplementował Codex?

W konfiguracji Playwright powstały dwa niezależne projekty:

api uruchamia testy nie-adminowe na API_BASE_URL,
admin-api wybiera testy z katalogu tests/api/admin i korzysta z API_ADMIN_BASE_URL.

Projekty nie mają zależności między sobą, a konfiguracja zachowuje fullyParallel: true. Dzięki temu mogą działać równolegle w jednym pełnym uruchomieniu.

Do package.json dodano komendy:

npm test — oba projekty,
npm run test:api — tylko ścieżka nie-adminowa,
npm run test:admin — tylko ścieżka adminowa.

Powstały także:

konfiguracja admina czytająca dane z .env,
bezpieczne placeholdery w .env.example,
fixture authenticatedAdmin, który loguje admina osobno dla każdego testu,
fixture authenticatedStagingUser, który tworzy użytkownika ROLE_CLIENT i usuwa go po teście,
rozszerzenia klientów użytkowników i produktów potrzebne do setupu oraz cleanupu,
typy requestów i odpowiedzi dla produktów,
generator produktu oparty na Fakerze i obsługujący nadpisywanie wybranych pól,
testy logowania admina dla statusów 200 i 422,
testy tworzenia produktu dla statusów 201, 400, 401 i 403.

Plan testów oraz README zostały zaktualizowane o dwa URL-e, zmienne środowiskowe, komendy i wyniki discovery.

Jakie korekty zostały zlecone po implementacji?

Pierwsza korekta dotyczyła ergonomii uruchamiania. Sama konfiguracja projektów Playwright nie wystarczała jako czytelny interfejs dla kursanta, dlatego pojawiły się osobne skrypty test:api i test:admin.

Druga korekta dotyczyła danych testowych. Lokalna funkcja budująca produkt z randomUUID() została zastąpiona współdzielonym productGenerator, który używa Fakera tak samo jak generator użytkownika. Test zachował możliwość podania override'ów dla scenariuszy walidacyjnych.

Co wyszło w review?

Review potwierdziło, że dwa projekty wskazują różne bazowe URL-e i nie dublują tych samych speców. Testy adminowe zachowują kolejność przypadków według kodów odpowiedzi, inicjalizują klientów w setupie oraz stosują sekcje given, when, then.

Sekret admina nie trafił do śledzonych plików. Plik .env pozostał ignorowany, a .env.example zawiera wyłącznie puste wartości. Tymczasowe produkty i konta są usuwane, więc równoległe uruchomienia nie współdzielą modyfikowanych rekordów.

Wynik testów

W trakcie sesji uzyskano następujące wyniki:

baseline przed implementacją: 59 testów zaliczonych,
nowe testy adminowe: 6 testów zaliczonych,
tylko projekt api: 59 testów zaliczonych,
tylko projekt admin-api: 6 testów zaliczonych,
test generatora produktu: 4 testy zaliczone,
pełny suite po implementacji: 65 testów zaliczonych.

Finalny efekt sesji

Projekt obsługuje dwie równoległe ścieżki testów API działające na osobnych środowiskach. Admin ma własną konfigurację, fixture'y, dane testowe, cleanup i pierwsze scenariusze autoryzacji oraz tworzenia produktu. Zwykłe testy nadal korzystają z awesome.byst.re, a testy adminowe z resetowanego stagingu aitesters.byst.re.