Awesome Testing
Request training offer

Markdown document

Plan implementacji

Lekcja 10: Zadanie 2 - rozwiązanie

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

Plan implementacji automatyzacji

Cel

Pokryć testami osiem kolejnych endpointów API po wcześniejszym sprawdzeniu ich zachowania na żywej aplikacji:

  • GET /api/v1/traffic/info
  • GET /api/v1/traffic/logs
  • GET /api/v1/products
  • GET /api/v1/products/{id}
  • GET /api/v1/users/chat-system-prompt
  • PUT /api/v1/users/chat-system-prompt
  • GET /api/v1/users/tool-system-prompt
  • PUT /api/v1/users/tool-system-prompt

Założenia po eksploracji

  • Endpoint traffic/info jest publiczny i zwraca stabilny, deterministyczny obiekt.
  • Endpoint traffic/logs jest publiczny, ale dane są dynamiczne, więc testy powinny sprawdzać strukturę i paginację, nie konkretną liczbę logów.
  • Endpointy produktowe wymagają autoryzacji.
  • GET /api/v1/products/{id} można testować przez pobranie pierwszego produktu z listy i użycie jego id.
  • Endpointy promptów wymagają autoryzacji i mają domyślne wartości dla nowego użytkownika.
  • Poprawny PUT prompta zapisuje wartość i można ją potwierdzić kolejnym GET.
  • Prompt dłuższy niż 5000 znaków zwraca 400, mimo że OpenAPI nie dokumentuje tego statusu dla operacji PUT.
  • Payload z błędnym polem zwraca 200 i zapisuje null; to zachowanie należy zgłosić jako błąd, a nie utrwalać w testach regresji.

Plan zmian

  1. Dodać typy odpowiedzi:

    • types/traffic.ts
    • types/products.ts
    • typy promptów w types/users.ts

  2. Dodać klientów HTTP:

    • TrafficClient
    • ProductsClient
    • metody promptów w UsersClient

  3. Dodać testy ruchu:

    • tests/api/traffic/info.spec.ts
    • tests/api/traffic/logs.spec.ts

  4. Dodać testy produktów:

    • tests/api/products/products.get.spec.ts
    • tests/api/products/id.get.spec.ts

  5. Dodać testy promptów:

    • tests/api/users/chat-system-prompt.get.spec.ts
    • tests/api/users/chat-system-prompt.put.spec.ts
    • tests/api/users/tool-system-prompt.get.spec.ts
    • tests/api/users/tool-system-prompt.put.spec.ts

  6. Zaktualizować api-test-plan.md:

    • dopisać wyniki eksploracji,
    • oznaczyć osiem endpointów jako ukończone,
    • poprawić stary zapis o pełnym suite z l7 na l8.

Zasady implementacji

  • Inicjalizować klientów HTTP w test.beforeEach.
  • Używać komentarzy given, when, then.
  • Grupować testy po statusach w kolejności rosnącej: 200, 400, 401, 404.
  • Dla danych dynamicznych stosować asercje strukturalne.
  • Nie dodawać testu dla błędnego pola prompta, dopóki zespół nie zdecyduje, czy obecne zachowanie ma zostać utrzymane.

Weryfikacja

Najpierw uruchomić tylko nowe testy:

npx playwright test tests/api/traffic/info.spec.ts tests/api/traffic/logs.spec.ts tests/api/products/products.get.spec.ts tests/api/products/id.get.spec.ts tests/api/users/chat-system-prompt.get.spec.ts tests/api/users/chat-system-prompt.put.spec.ts tests/api/users/tool-system-prompt.get.spec.ts tests/api/users/tool-system-prompt.put.spec.ts

Następnie uruchomić pełny zestaw:

npm test