Awesome Testing
Request training offer

Markdown document

Zadanie

Lekcja 13: Zadanie 3 - testy Mocka LLM

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

Zadanie: testy Mocka LLM

Przygotuj testy API w Playwright dla endpointów Mocka LLM. Celem zadania jest sprawdzenie kontraktu backendu dla odpowiedzi streamingowych, a nie ocenianie jakości odpowiedzi modelu językowego.

Zanim poprosisz agenta AI o implementację, zacznij od nauki. To jest nowy typ endpointów w projekcie: streaming HTTP po stronie backendu i event stream po stronie klienta. Poproś agenta, żeby najpierw wyjaśnił Ci, jak działa mock, jak backend wystawia te endpointy, jak odpowiedź jest budowana token po tokenie i co w takim streamie realnie warto testować.

Dopiero po tej sesji nauki przejdź do standardowego flow ze skilla w repo: eksploracja, plan, implementacja, testy, review i commit. Plan w tym zadaniu trzeba przeczytać szczególnie dokładnie, bo nie jest to powtarzalny endpoint JSON, tylko nowy mechanizm testowy.

Endpointy do pokrycia

Użyj poniższych operacji:

GET /api/v1/ollama/chat/tools/definitions
POST /api/v1/ollama/generate
POST /api/v1/ollama/chat
POST /api/v1/ollama/chat/tools

Krótki opis endpointów:

  • GET /api/v1/ollama/chat/tools/definitions zwraca definicje narzędzi dostępnych dla tool callingu, między innymi get_product_snapshot i list_products.
  • POST /api/v1/ollama/generate przyjmuje pojedynczy prompt i zwraca odpowiedź jako strumień zdarzeń.
  • POST /api/v1/ollama/chat przyjmuje historię wiadomości i zwraca strumieniowaną odpowiedź asystenta.
  • POST /api/v1/ollama/chat/tools przyjmuje wiadomości oraz definicje narzędzi, a następnie może zwrócić tool call, wynik narzędzia i finalną odpowiedź asystenta.

Wszystkie endpointy z tej grupy wymagają autoryzacji JWT, więc testy powinny korzystać z istniejącego fixture zalogowanego użytkownika.

Zanim zaczniesz implementację

Najpierw zrób krótką sesję nauki z agentem. Daj mu kontekst potrzebny do zrozumienia mechanizmu:

  • kod backendu, który wystawia endpointy Ollamy,
  • kod kontrolowanego mocka LLM,
  • aktualny plan testów API,
  • istniejące fixture'y, klientów HTTP i helpery testowe.

Poproś agenta, żeby wyjaśnił:

  • czym różni się zwykła odpowiedź JSON od text/event-stream,
  • jak backend streamuje odpowiedź do klienta,
  • jak mock zapewnia determinizm odpowiedzi,
  • co oznaczają kolejne zdarzenia data:,
  • gdzie w streamie pojawia się końcowe done=true,
  • które elementy odpowiedzi są stabilnym kontraktem, a które są dynamiczne.

Nie pomijaj tego kroku. W tej lekcji celem jest nie tylko dopisanie testów, ale też zrozumienie, jak testować integracje LLM-like bez uzależniania się od prawdziwego modelu.

Jak pracować z agentem AI

W tym zadaniu użyj skilla z repozytorium i poprowadź agenta przez standardowy proces, ale wolniej niż przy prostych endpointach:

  1. Zacznij od sesji nauki opisanej wyżej.
  2. Uruchom flow ze skilla: eksploracja, plan, implementacja, testy, review i commit.
  3. Poproś o przeczytanie aktualnego api-test-plan.md oraz istniejących helperów HTTP.
  4. Poproś o sprawdzenie OpenAPI i, jeśli to możliwe, krótką eksplorację live API przez curl z nagłówkiem Accept: text/event-stream.
  5. Poproś o plan helpera do parsowania SSE: jak zbierze zdarzenia data:, jak sparsuje JSON i jak znajdzie końcowe done=true.
  6. Przeczytaj plan bardzo dokładnie przed implementacją. Sprawdź, czy agent rozumie streaming, mock, autoryzację, dynamiczne pola i granice stabilnych asercji.
  7. Poproś o plan implementacji plików testowych i danych testowych.
  8. Po implementacji poproś o review diffu, żeby sprawdzić stabilność asercji.
  9. Na końcu poproś o uruchomienie nowych testów, pełnego suite'u API i aktualizację planu testów.

Jeżeli korzystasz z narzędzia, które pozwala wybrać mocniejszy model albo wyższy reasoning, warto to zrobić na etap nauki, eksploracji i planowania. To jest nowe, trudniejsze zadanie, więc lepiej dostać wolniejszą, ale dokładniejszą analizę. Przy samej implementacji możesz wrócić do tańszego modelu, jeżeli plan jest już jasny.

Kryteria akceptacji

  • GET /api/v1/ollama/chat/tools/definitions ma test odpowiedzi 200 oraz test braku autoryzacji 401.
  • POST /api/v1/ollama/generate ma test poprawnego streamu, walidacji błędnego body 400 oraz braku autoryzacji 401.
  • POST /api/v1/ollama/chat ma test poprawnego streamu, walidacji pustej listy wiadomości 400 oraz braku autoryzacji 401.
  • POST /api/v1/ollama/chat/tools ma test poprawnego przepływu tool callingu, walidacji brakujących narzędzi 400 oraz braku autoryzacji 401.
  • Testy sprawdzają text/event-stream dla endpointów streamingowych.
  • Testy potrafią zebrać wiele zdarzeń SSE i znaleźć końcowe zdarzenie done=true, jeżeli jest stabilne w aktywnym mocku.
  • Asercje sprawdzają stabilny kontrakt: statusy, content type, strukturę zdarzeń, deterministyczną treść mocka, nazwę toola i argumenty tool calla.
  • Testy nie zakładają dokładnej liczby chunków, dynamicznych identyfikatorów tool calli ani timingów streamu.
  • Przypadek brakującego modelu jest dodany tylko wtedy, gdy aktualne środowisko rzeczywiście zwraca stabilny błąd, a nie poprawny stream z kontrolowanego mocka.
  • Przed implementacją została wykonana sesja nauki z agentem: mock, backend, streaming HTTP, event stream i deterministyczne odpowiedzi są zrozumiane.
  • Do pracy został użyty skill z repozytorium, a plan agenta został świadomie przejrzany przed kodowaniem.
  • Plan testów API jest zaktualizowany po implementacji.
  • Nowe testy i pełny suite API zostały uruchomione.
  • Review diffu nie wskazuje zmian niezwiązanych z zadaniem.