Давај пример како би изабрао тест случајеве за PUT захтев.

Izbor test slučajeva za PUT zahteve je usmeren na proveru ispravnog ažuriranja resursa, obrade različitih tipova podataka i negativnih scenarija.

Primeri test slučajeva:

1. Pozitivan scenario (uspešno ažuriranje):

   • Ažuriranje resursa sa svim validnim poljima.
   • Ažuriranje resursa samo sa delom validnih polja (ako API omogućava delimično ažuriranje).
   • Ažuriranje polja različitim tipovima podataka (nizovi, brojevi, logičke vrednosti), ako je to predviđeno šemom.
   • Ažuriranje resursa sa minimalno dozvoljenim vrednostima (ako je primenjivo).
   • Ažuriranje resursa sa maksimalno dozvoljenim vrednostima (ako je primenjivo).

2. Negativni scenariji (greške i izuzeci):

   • Pokušaj ažuriranja nepostojećeg resursa. Očekivani odgovor: 404 Not Found.
   • Slanje zahteva bez tela. Očekivani odgovor: 400 Bad Request ili 422 Unprocessable Entity.
   • Slanje zahteva sa nevažećim formatom tela (npr. nevažeći JSON). Očekivani odgovor: 400 Bad Request.
   • Slanje zahteva sa nevažećim tipovima podataka za polja. Na primer, niz umesto broja. Očekivani odgovor: 400 Bad Request ili 422 Unprocessable Entity.
   • Slanje zahteva sa izostavljenim obaveznim poljima. Očekivani odgovor: 400 Bad Request ili 422 Unprocessable Entity.
   • Slanje zahteva sa vrednostima koje premašuju dozvoljenu dužinu ili opseg. Očekivani odgovor: 400 Bad Request ili 422 Unprocessable Entity.
   • Slanje zahteva sa nevažećom vrednošću u putanji (npr. nevažeći ID). Očekivani odgovor: 400 Bad Request ili 404 Not Found.
   • Pokušaj ažuriranja blokiranog ili nedostupnog resursa (ako je primenjivo). Očekivani odgovor: 403 Forbidden ili 409 Conflict.
   • Slanje zahteva sa neispravnim zaglavljima (npr. Content-Type). Očekivani odgovor: 415 Unsupported Media Type ili 400 Bad Request.
   • Ažuriranje korišćenjem specijalnih karaktera ili emoji-ja u nizovima.

3. Granični uslovi:

   • Ažuriranje polja sa graničnim vrednostima (npr. minimalni/maksimalni datum, granični brojevi).
   • Ažuriranje polja sa praznim nizovima ili null vrednostima (ako je to dozvoljeno).

4. Scenariji paralelnog pristupa:

   • Istovremeni pokušaj ažuriranja istog resursa iz više izvora.

5. Provera posledica ažuriranja:

   • Provera da su podaci ispravno ažurirani u bazi podataka ili drugim sistemima.
   • Provera da su zavisni resursi ili podaci ažurirani/izmenjeni na odgovarajući način.
   • Provera da GET zahtev na ažurirani resurs vraća aktuelne podatke.
   • Provera da druge operacije (DELETE, POST) sa ažuriranim resursom funkcionišu ispravno.

Kriterijumi za izbor konkretnih test slučajeva zavise od specifikacije API-ja, poslovnih zahteva, analize rizika i prioriteta. Koriste se tehnike test dizajna poput ekvivalentnog deljenja i analize granica, za određivanje najvažnijih ulaznih podataka.