Podaj przykład, jak wybrałbyś przypadki testowe dla żądania PUT.

Dobór przypadków testowych dla żądań PUT ma na celu sprawdzenie poprawnej aktualizacji zasobu, obsługi różnych typów danych i scenariuszy negatywnych.

Przykłady przypadków testowych:

1. Scenariusz pozytywny (udana aktualizacja):

   • Aktualizacja zasobu wszystkimi poprawnymi polami.
   • Aktualizacja zasobu tylko częściowo poprawnymi polami (jeśli API pozwala na częściowe aktualizacje).
   • Aktualizacja pól różnymi typami danych (łańcuchy, liczby, wartości logiczne), jeśli jest to przewidziane w schemacie.
   • Aktualizacja zasobu minimalnie dozwolonymi wartościami (jeśli dotyczy).
   • Aktualizacja zasobu maksymalnie dozwolonymi wartościami (jeśli dotyczy).

2. Scenariusze negatywne (błędy i wyjątki):

   • Próba aktualizacji nieistniejącego zasobu. Oczekiwana odpowiedź: 404 Not Found.
   • Wysłanie żądania bez ciała. Oczekiwana odpowiedź: 400 Bad Request lub 422 Unprocessable Entity.
   • Wysłanie żądania z nieprawidłowym formatem ciała (np. nieprawidłowy JSON). Oczekiwana odpowiedź: 400 Bad Request.
   • Wysłanie żądania z nieprawidłowymi typami danych dla pól. Na przykład, ciąg zamiast liczby. Oczekiwana odpowiedź: 400 Bad Request lub 422 Unprocessable Entity.
   • Wysłanie żądania z pominiętymi obowiązkowymi polami w ciele. Oczekiwana odpowiedź: 400 Bad Request lub 422 Unprocessable Entity.
   • Wysłanie żądania z polami przekraczającymi dozwoloną długość/zakres. Oczekiwana odpowiedź: 400 Bad Request lub 422 Unprocessable Entity.
   • Wysłanie żądania z nieprawidłową wartością w ścieżce (np. nieprawidłowe ID). Oczekiwana odpowiedź: 400 Bad Request lub 404 Not Found.
   • Próba aktualizacji zablokowanego lub niedostępnego zasobu (jeśli dotyczy). Oczekiwana odpowiedź: 403 Forbidden lub 409 Conflict.
   • Wysłanie żądania z niepoprawnymi nagłówkami (np. Content-Type). Oczekiwana odpowiedź: 415 Unsupported Media Type lub 400 Bad Request.
   • Aktualizacja z użyciem specjalnych znaków lub emoji w polach tekstowych.

3. Warunki brzegowe:

   • Aktualizacja pól z wartościami granicznymi (np. minimalna/maksymalna data, graniczne liczby).
   • Aktualizacja pól z pustymi ciągami lub wartościami null (jeśli dozwolone).

4. Scenariusze dostępu równoległego:

   • Równoczesna próba aktualizacji tego samego zasobu z różnych źródeł (jeśli jest to istotne dla testowanego systemu).

5. Weryfikacja skutków aktualizacji:

   • Sprawdzenie, czy dane zostały poprawnie zaktualizowane w bazie danych lub innych systemach.
   • Sprawdzenie, czy zależne zasoby lub dane zostały zaktualizowane/zmienione odpowiednio (jeśli istnieją zależności).
   • Sprawdzenie, czy zapytanie GET do zaktualizowanego zasobu zwraca aktualne dane.
   • Sprawdzenie, czy inne operacje (DELETE, POST) z zaktualizowanym zasobem działają poprawnie.

Kryteria wyboru konkretnych przypadków testowych zależą od specyfikacji API, wymagań biznesowych, analizy ryzyka i priorytetów. Używa się technik projektowania testów, takich jak podział na równoważne i analiza granic, aby wybrać najbardziej reprezentatywne dane wejściowe.