W tej lekcji użyjemy metody, która umożliwia tworzenie obiektów w API. Przestaniemy więc tylko wyciągać informacje poprzez zapytania, a zaczniemy tworzyć nowe obiekty.
Dokumentacja do sklepu
Po poprawnym postawieniu aplikacji dokumentację do niej znajdziesz pod localhost/fakestore/dokumentacja/. Tam też znajdziesz np. klucze potrzebne do uwierzytelnienia.
Wersja Javy
W zależności od tego której wersji Javy używasz, mogą się pojawić drobne rozbieżności w sytuacji, w których pobieramy jakąś informację z odpowiedzi metodą get(), a następnie ją „wypluwamy” w konsoli metodą println, np.:
System.out.println(response.jsonPath().get("name"));
Jeżeli nie zadziała Ci to, co pokazuję (będzie się podkreślało na czerwono i po najechaniu zobaczysz „Ambiguous method call”) możesz zamiast get() użyć metody getString():
System.out.println(response.jsonPath().getString("name"));
Tworzenie obiektów w API: linki i materiały
W tej lekcji połączymy trzy narzędzia, które już znamy:
- dokumentację – z niej dowiemy się jak tworzyć nowe obiekty (jakiej metody użyć), czy i jakie pola obiektów są wymagana oraz jakiej odpowiedzi się spodziewamy,
- Postmana – w nim sprawdzimy, czy to co przedstawione jest w dokumentacji faktycznie działa i jak wygląda,
- REST Assured – przeniesiemy taki twór do kodu.
Tworzenie obiektów w API – metoda POST
Dodamy także nową metodę testową do istniejącej już klasy. Zaczniemy tak samo, jak wcześniej, czyli od given(). Ten fragment będzie bliźniaczo podobny, do tego, co już znamy z ostatniej lekcji jednak, żeby stworzyć obiekt musimy dostarczyć dwóch dodatkowych informacji. Potrzebujemy:
- zdefiniować typ zawartości (dobrze, że programujemy w JAVIE i jesteśmy przyzwyczajeni do jawnego typowania), czyli pojawi się u nas:
.contentType(“application/json”)
- dodać zawartość ciała requestu – czyli wypełnić body
.body(“Tu wpisujemy nasz json!”)
Pamiętajcie, że nie wysyłamy już zapytania z metodą .get(), tylko .post() i wskazujemy enpoint. Jeśli pamiętacie jeszcze początkowe lekcje to w zależności od metody okaże się, że ten sam endpoint czasem listuje produkty, a czasem je tworzy – tak ma być, ale to znaczy, że warto bacznie się przyglądać, którą metodę macie wybraną (szczególnie w Postmanie).
Okaże się też, że sama asercja na kodzie może sprawić… że nie wiemy co stworzyliśmy. Tak, ID nowo utworzonego obiektu przychodzi w responsie do tworzącego go POSTa! Warto tę wartość pobierać, albo chociaż wypisywać, by móc jej potem użyć.
CRUD
Na filmie wspominam też o akronimie CRUD, tego co oznacza oraz zwrócę uwagę, że naszymi testami pokrywamy już jego połowę. Możemy więc stworzyć obiekt (C od create), a następnie odczytać go (R od read) i upewnić się, że stworzył się prawidłowo (przynajmniej na tyle, na ile nas to interesowało).
Warto wspomnieć, że o ile to zwykle dane są tym, co powinno nas w testach interesować, to kod odpowiedzi jest warunkiem koniecznym, do potwierdzenia, że komunikacja w ogóle miała szanse zajść prawidłowo – dlatego będę go sprawdzał do znudzenia, co i Wam polecam.
W ramach pracy własnej – pobawcie się tworzeniem obiektów – bardziej rozbudujcie wysyłane body, zobaczcie na ile nasze API pozwoli Wam ustawiać wartości, a do których nie da Wam dostępu. Ciekaw jestem z jakim największym body uda się Wam stworzyć produkt 🙂
Komentarze
Nie masz aktywnej subskrypcji. Wykup subskrypcję albo zaloguj się, by móc komentować.