Awesome Testing
Request training offer

Markdown document

Zadanie

Lekcja 24: Zadanie 5 — inventory

Historical artifacts may name disposable training credentials and environments. Do not reuse credentials, target course systems, or execute archived prompts without authorization.

Zadanie 5: zrozum i przetestuj inventory

Cel zadania

Zanim poprosisz agenta o kolejną porcję testów, ustal, co inventory oznacza w tej aplikacji. Wyjaśnij związek pomiędzy dostępną ilością produktów, koszykiem i zamówieniami. Dopiero na tej podstawie uzgodnij zakres automatyzacji. To ostatnie zadanie kursu; punktem wyjścia jest projekt mający 170 testów.

Punkt startowy i kontekst dla agenta

Pracuj w ait2api1-api-ai/l19. Jest to stan przed dodaniem testów inventory. Nie zaczynaj od l20, ponieważ ten checkpoint zawiera rozwiązanie.

Udostępnij agentowi repozytorium backendu test-secure-backend, istniejące specy, klientów HTTP, fixture, api-test-plan.md, AGENTS.md oraz repozytoryjny workflow api-testing-skill. Zachowaj bieżący podział na projekty kliencki i administracyjny. Nie kopiuj poświadczeń do wiadomości ani kodu.

Najpierw rozpoznanie biznesowe i techniczne

Porozmawiaj z agentem o tym, jak działa inwentarz. Nie wystarczy odpowiedź, że endpoint zwraca liczbę produktów. Poproś o prześledzenie kodu backendu: skąd ta liczba pochodzi, kiedy się zmienia i czy jest połączona z rzeczywistym przepływem zamówienia albo zewnętrznym systemem magazynowym. Nie zakładaj, że aplikacja szkoleniowa realizuje wszystkie reguły prawdziwego sklepu.

Ustal wspólnie, jakie zachowania wymagają szczególnej uwagi. Sprawdź, czy samo dodanie do koszyka ma wpływ na dostępność, co dzieje się podczas utworzenia i anulowania zamówienia oraz jak administrator koryguje stan. Zapytaj także, czy implementacja wymaga specjalnego sposobu testowania. Odpowiedź „nie” powinna mieć uzasadnienie oparte na kodzie i obserwacjach.

Porównaj istniejące testy backendowe z tym, co warto sprawdzić przez publiczny interfejs HTTP. Jeżeli coś jest niejasne, zweryfikuj to przez API na własnych danych, zgodnie z workflow projektu. Nie utrwalaj domysłów w asercjach.

Następnie automatyzacja

Po wyjaśnieniu działania funkcji poproś agenta o testy czterech operacji:

  • GET /api/v1/admin/inventory,
  • GET /api/v1/admin/inventory/{productId},
  • POST /api/v1/admin/inventory/{productId}/adjustments,
  • GET /api/v1/admin/inventory/{productId}/movements.

Dobierz happy pathy, kontrolę dostępu i istotne przypadki negatywne do potwierdzonego zachowania. Sprawdzaj skutek operacji, a nie tylko status HTTP. Użyj istniejącego stylu: klienty w test.beforeEach, given/when/then oraz rosnące grupy kodów odpowiedzi. Nowy helper powinien ułatwiać czytanie testu, a nie wprowadzać odmienną konwencję tylko dla jednego katalogu.

Testy stanowe muszą posiadać własne produkty, użytkowników i zamówienia oraz posprzątać po sobie także przy niepowodzeniu. Jeżeli wykryjesz niespójność backendu lub kontraktu, zachowaj kroki odtworzenia i zgłoś ją zgodnie z bramką defektów projektu. Nie osłabiaj asercji wyłącznie po to, żeby uzyskać zielony run.

Kryteria akceptacji

  • Potrafisz wyjaśnić, co jest źródłem stanu inventory i kiedy się on zmienia.
  • Decyzję o zakresie i poziomie testów uzasadniasz kodem, istniejącymi testami backendowymi i obserwacją API.
  • Cztery operacje mają sensowne testy w odpowiednim projekcie Playwright.
  • Dane testowe są izolowane, cleanup działa, a sekrety pozostają poza kodem.
  • api-test-plan.md odzwierciedla zakres, ograniczenia i ewentualne defekty.
  • Najpierw przechodzą nowe lub zmienione testy, a następnie pełny zestaw.
  • Kod został przeczytany pod kątem stylu i utrzymania, niezależnie od wyniku testów.

Nie ma wymaganej liczby nowych testów. Nie trzeba używać konkretnego modelu, Goal, subagentów ani specjalnej biblioteki. Najważniejsze jest uzasadnienie rozwiązania i jego weryfikacja. Gotowego kodu z l20 użyj dopiero do porównania po własnej próbie.

Opcjonalne ćwiczenia po zadaniu

Jeżeli oczekiwanie na kody TOTP spowalnia pracę, poproś agenta o propozycję wydzielenia wolniejszych testów 2FA do osobnego zestawu. Zadbaj, aby nadal można było uruchomić całą regresję. To dobrowolny refaktor, a nie warunek rozwiązania inventory.

Możesz również porozmawiać z agentem o wadach projektu, zbędnych powtórzeniach lub kosztownych testach. Oceń propozycje przed zmianą kodu i sprawdź, czy rzeczywiście poprawiają czytelność lub czas pracy. Te rozszerzenia są zachętą do dalszej praktyki po kursie, nie dodatkowymi wymaganiami tego zadania.