API w REST Assured 9. CRUD: PUT i PATCH oraz niezależność testów

W tej lekcji poruszymy temat metod PUT i PATCH. Metodę PUT co prawda już poznaliśmy, ale dzisiaj zobaczysz czym się ona różni od PATCH i do czego się jej używa.

System.out.println(response.jsonPath().get("name"));

System.out.println(response.jsonPath().getString("name"));

CRUD: PUT i PATCH

Do tej pory poznaliśmy metodę PUT jako sposób na modyfikację obiektów. Po co w takim razie jest metoda PATCH i czy da się jej użyć w naszym API?

Różnice pomiędzy PUT i PATCH

Różnica pomiędzy PUTem i PATCHem jest często bardzo kosmetyczna, a w niektórych API  (tak jak w przypadku naszego) żadna. Filozofia stojąca za rozróżnieniem tych dwóch metod wynika z dwóch podejść do przechowywania danych (historycznie – w bazach danych).

Jedno z podejść polega na tym, że raz dodany do bazy rekord nie jest już nigdy modyfikowany, a jeśli chcemy zmienić dane, to tworzymy rekord o tym samym ID, ale nowszej wersji (lub rewizji). W takim podejściu – jeśli pobieramy dane, to domyślnie są nam serwowane te najnowsze, chyba, że prosimy o konkretną w2rsję. Stąd jest to dobry sposób jeśli chcemy przechowywać historię obiektów. Takie podejście wspiera metoda PUT – zgodnie ze standardem zamieni ona istniejący obiekt na ten dostarczony przez nas – stworzy nową wersję obiektu.

Drugie podejście do przechowywania danych pozwala na modyfikację istniejącego obiektu – tu do głosu dochodzi PATCH. Istnieją systemy, które umożliwiają świadomym użytkownikom obie akcje – tzn jeśli chcesz stworzyć nową wersję, proszę bardzo, użyj PUTa, jeśli chcesz zmienić istniejącą – PATCH jest dla Ciebie. 

A jak to jest w naszym API?

Nasze API wbrew temu co mówi dokumentacja (wymienia tylko PUTa) pozwala na modyfikację danych aż na trzy różne sposoby – działają zarówno PUT, jak i PATCH, a dodatkowo POST wysłany do konkretnego obiektu również go zmieni. Nie jest to jednak typowe podejście i radziłbym Wam zapamiętać, że jest raczej niezgodne ze standardem. 

Niezależność testów

Ponieważ znamy już wszystkie potrzebne metody, sposoby ich użycia i wyciągamy uniwersalne dane poza konkretne testy to warto wspomnieć jeszcze o jednej dobrej praktyce testowania: niezależności testów! Każdy test powinien być niepowiązany z pozostałymi, testować pojedynczą (i możliwie małą funkcjonalność). Czyli na przykładzie kasowania – taki test powinien testować tylko kasowanie.

Wyobraźmy sobie jednak sytuację w której przestaje nam działać tworzenie obiektów (ten test failuje), ale kasowanie działa super. Jeśli listujemy obiekty, a potem kasujemy np. pierwszy z listy, to może się okazać, że nasze testy automatyczne skasowały wszystkie dane z systemu, a nie mamy do czasu naprawy tego błędy sposobu na stworzenie nowych. Dlatego moje podejście jest takie, że możemy wykonać więcej czynności, pamiętając jednak, że naszą główną, pożądaną asercją jest ta sprawdzająca kasowanie. Podobnie możemy podejść do zmiany obiektu. Możemy zmieniać w kółko ten sam obiekt (np. zmieniając nazwę na System.currentTimeMillis() – czyli aktualny czas wyrażony w milisekundach) albo stworzyć obiekt i sprawdzić czy taki nowo utworzony obiekt da się też zmodyfikować. 

Kod z lekcji