Awesome Testing

Markdown document

Podsumowanie sesji Codex

Lekcja 3: Testy API dla endpointu signup

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 testów API dla endpointa rejestracji użytkownika.

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

  1. Eksploracja endpointa /users/signup przed pisaniem testów.
  2. Implementacja testów rejestracji w Playwright.
  3. Dodanie generatora losowych danych testowych z użyciem Faker.js.
  4. Review zmian, poprawki nazw i aktualizacja dokumentacji.

Prompty użyte w Codex

I wish to cover /users/signup tests now. Before I start please perform some exploratory tests, see README.md and api-docs.json on how to perform them
where there any bugs?
I’m working on API tests in a Playwright project. I want to cover the registration endpoint with tests. You have access to the API docs, so check the request schemas there. You also understand what response codes can be returned, so verify that as well based on the docs. For registration, make sure the test data is random. Use Faker.js. Create a high-quality test data generator in the Generators folder. The generator should be well written, produce realistic random data, and support users from different countries because this is an international application. Create the registration tests as well. Run the tests and make sure they pass. I’ll review everything afterwards.
Do we enforce that username is at least 4 chars?
Rename Generators folder to generators
rename generators to generator
Rename the method to generatorUser, not signup const user = UserGenerator.signupUser();
generateUser
do not cleanup the user yet
ok, update docs

Co sprawdził Codex przed implementacją?

Codex najpierw sprawdził dokumentację API i wykonał eksploracyjne requesty do endpointa rejestracji.

W eksploracji potwierdził między innymi:

  • poprawna rejestracja zwraca 201,
  • odpowiedź dla poprawnej rejestracji nie zawiera body,
  • duplikat danych użytkownika zwraca błąd 400,
  • błędne dane wejściowe są walidowane,
  • dokumentacja opisuje też limitowanie requestów przez 429, ale nie było sensownego powodu, żeby wymuszać ten przypadek w automatycznym teście.

Po pytaniu o potencjalne bugi Codex wskazał obserwacje z eksploracji, ale nie zgłosił blokującego błędu uniemożliwiającego pisanie testów.

Co zaimplementował Codex?

Codex przygotował testy rejestracji i potrzebne wsparcie techniczne:

  • dodał Faker.js do projektu,
  • rozszerzył typy requestów i odpowiedzi związanych z auth,
  • rozszerzył klienta API o obsługę rejestracji,
  • dodał generator użytkowników z losowymi, realistycznymi danymi,
  • dodał testy endpointa signup,
  • ułożył przypadki testowe według kodów odpowiedzi,
  • uruchomił testy i poprawił problemy wykryte podczas wykonania.

W trakcie implementacji Codex poprawił też problem z użyciem Faker locale, żeby generator działał poprawnie.

Jakie korekty zostały zlecone po implementacji?

Po pierwszej wersji kodu wprowadzono kilka korekt nazewnictwa i zakresu:

  • folder Generators został przemianowany na generators,
  • następnie folder został przemianowany na generator,
  • metoda generatora została finalnie nazwana generateUser,
  • usunięto cleanup utworzonego użytkownika, bo na tym etapie lekcji nie miał być jeszcze wykonywany.

Codex sprawdził też, czy username o długości poniżej 4 znaków jest walidowany przez API.

Co wyszło w review?

W review Codex zauważył, że konfiguracja wymaga nowej zmiennej API_USER_EMAIL, ale dokumentacja nie opisywała jej jeszcze wystarczająco jasno.

Po poleceniu aktualizacji dokumentacji Codex dopisał brakującą informację do README.

Wynik testów

Po implementacji testy rejestracji przechodziły:

7 passed

Po końcowych poprawkach dokumentacyjnych nie było potrzeby ponownego uruchamiania testów, bo zmiana dotyczyła tylko README.

Finalny efekt sesji

Po tej sesji projekt miał testy API dla rejestracji użytkownika:

  • endpoint signup został wcześniej sprawdzony eksploracyjnie,
  • testy używały losowych danych zamiast stałych użytkowników,
  • generator danych był wydzielony poza testy,
  • klient API obsługiwał rejestrację,
  • dokumentacja lokalnej konfiguracji została uzupełniona.