Awesome Testing
Request training offer

Markdown document

Podsumowanie sesji Codex

Prework: Discovery & Learning

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 była discovery przed rozpoczęciem produkcyjnych testów API i E2E. Codex miał przeanalizować trzy repozytoria tworzące system — backend, mock Ollamy i konfigurację LocalStack — a następnie doradzić stack, architekturę, zakres testów oraz realną skalę trudności.

Prompt startowy

Pełny prompt znajduje się w pliku chatgpt-prompt.txt. Najważniejsza intencja była prosta: najpierw zrozumieć system i ryzyka, dopiero potem wybrać narzędzia oraz plan automatyzacji.

Co sprawdził Codex?

Codex przeanalizował konfigurację wdrożeń i profile środowisk, żywe endpointy, OpenAPI, mechanizmy logowania, role, reset danych, integrację z mockiem Ollamy, kolejkę wiadomości i różnice w bazach danych.

Discovery potwierdziło dwa istotne środowiska:

  • aitesters.byst.re — środowisko sandbox przeznaczone do mutujących testów regresyjnych,
  • awesome.byst.re — stabilniejsze środowisko produkcyjne, na którym potrzebny jest mały i ostrożny canary suite.

Najważniejszy wniosek architektoniczny: testowanie wyłącznie sandboxa nie potwierdza działania całej infrastruktury produkcyjnej. Sandbox korzysta m.in. z H2 i lokalnego outboxa, podczas gdy produkcyjne środowisko ma PostgreSQL, ActiveMQ i konsumenta maili.

Rekomendowany stack

Codex zarekomendował osobne repozytorium z testami oparte na:

  • TypeScript,
  • Playwright Test,
  • APIRequestContext do testów REST,
  • natywnym fetch() lub małym parserze do SSE,
  • Zod do najważniejszych walidacji runtime,
  • opcjonalnie openapi-typescript do typów generowanych z kontraktu.

Playwright został wybrany dlatego, że pozwala utrzymać testy API i kilka krytycznych ścieżek przeglądarkowych w jednym runnerze, a jednocześnie daje fixture, projekty, równoległość, retry, raporty i trace.

Proponowane warstwy testów

Discovery podzieliło automatyzację na cztery warstwy:

  1. smoke testy deploymentu uruchamiane na obu środowiskach,
  2. pełna, mutująca regresja API na sandboxie,
  3. mały, serialny canary suite na produkcji,
  4. tylko kilka krytycznych scenariuszy w prawdziwej przeglądarce.

Wśród najważniejszych obszarów znalazły się: rejestracja i logowanie, rotacja refresh tokenów, autoryzacja ról, użytkownicy, produkty, koszyk, zamówienia, reset hasła, MFA, Ollama i SSE, redakcja sekretów oraz negatywne przypadki 401, 403, 404 i walidacja danych.

Strategia danych testowych

Codex wskazał, że stabilność testów będzie zależała głównie od izolacji danych. Każdy run powinien tworzyć unikalnych użytkowników i rekordy, a cleanup musi tolerować 404, bo sandbox może zostać zresetowany wcześniej. Współdzielone konta demonstracyjne nie powinny być mutowane.

Dla produkcyjnego canary suite rekomendacja to jeden worker, unikalna tożsamość dla każdego uruchomienia i usunięcie własnych danych po zakończeniu scenariusza.

API a testy przeglądarkowe

W follow-upie pojawiło się pytanie, czy przy wymaganiu „tylko testy API” warto dodawać testy UI. Odpowiedź Codex była pragmatyczna:

  • API suite powinien pozostać głównym i największym zakresem,
  • 2–3 browser smoke tests można uzasadnić jako kontrolę ryzyka poza API,
  • przeglądarka wykrywa problemy integracji frontendu, routingu, cookies, CORS i kompletnego flow użytkownika, których bezpośrednie requesty API nie zobaczą,
  • jeżeli zakres organizacyjny naprawdę zabrania UI, te scenariusze należy opisać jako osobny residual-risk recommendation, a nie przemycać do API suite.

Skala trudności

Start jest stosunkowo prosty, ale produkcyjna niezawodność ma średnią lub wysoką trudność. Najwięcej pracy wymagają MFA, reset hasła, SSE, izolacja danych, cleanup, diagnostyka awarii oraz harmonogram testów po wdrożeniu.

Szacunek z discovery:

  • użyteczny smoke suite: 1–2 dni,
  • krytyczna regresja API: kolejne 3–5 dni,
  • MFA, reset hasła, SSE, schema checks i utwardzenie CI: kolejne 3–6 dni,
  • dojrzała pierwsza wersja: około 1–2 tygodni pracy.

Finalny rezultat

Pełny wynik discovery zapisany przez Codex podczas nagrania znajduje się w api-e2e-testing-discovery.md. Sesja nie implementowała jeszcze testów. Jej rezultatem była uzasadniona decyzja technologiczna, mapa środowisk i ryzyk, proponowana struktura repozytorium, lista obszarów testowych oraz realistyczny plan dalszej pracy.