• Przejdź do głównej nawigacji
  • Przejdź do treści
  • Przejdź do głównego paska bocznego
  • Przejdź do stopki
Testelka.pl

Testelka.pl

Testelka.pl - o technologiach w testowaniu oprogramowania

  • Kursy
    • DARMOWY: Java dla testerów
    • Selenium w Javie
    • Selenium w C#
    • Testy API w REST Assured
    • Selektory CSS
    • XPath
  • Materiały na raz
  • Blog
  • O Eli
  • Zaloguj się
  • DOŁĄCZ

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

Strona główna > Kursy > Testy API w REST Assured > 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.

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"));

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

Ukryta treść

Nie masz aktywnej subskrypcji. Wykup subskrypcję albo zaloguj się, by móc zobaczyć pełną lekcję.

Reader Interactions

Komentarze

Nie masz aktywnej subskrypcji. Wykup subskrypcję albo zaloguj się, by móc komentować.

Komentarze

  1. Bartosz Kita napisał

    2 marca, 2020 o 10:06 am

    Kolejna bardzo fajna lekcja. W 100% się zgadzam z podeściem, żeby w teście, który kasuje obiekt, najpierw go stworzyć. Dziwi mnie tylko jedna rzecz w tym API, że przy POST i PUT nie trzeba wysłać całego JSONa.

    Odpowiedz
    • Kuba Rosiński napisał

      2 marca, 2020 o 5:15 pm

      Dzięki 🙂 W sumie dobrze, że o tym wspomniałeś [...] CAŁOŚĆ KOMENTARZA WIDOCZNA DLA SUBSKRYBENTÓW.

      Odpowiedz
      • Stanley92 napisał

        3 marca, 2020 o 7:53 am

        Pięknie, dwaj prowadzący szkolenia o API nauczają w komentarzach innych poruszając ważne tematy.

        Odpowiedz
        • Kuba Rosiński napisał

          3 marca, 2020 o 9:12 am

          Google, please index as "zdrowa konkurencja" 😀 [...] CAŁOŚĆ KOMENTARZA WIDOCZNA DLA SUBSKRYBENTÓW.

          Odpowiedz

Pierwszy Sidebar

LEKCJE W KURSIE

  • Lokalna aplikacja do testów za pomocą LocalWP lub XAMPP
  • Czym jest API?
  • Pierwsze zapytanie do API
  • Pierwszy test API - metoda GET
  • Tworzenie obiektów w API - metoda POST
  • Zadanie: tworzenie i pobieranie obiektów
  • Usuwanie i zmiana obiektów - metody DELETE i PUT
  • CRUD: wspólne elementy żądań
  • CRUD: PUT i PATCH oraz niezależność testów
  • Jak szperać w JSONie?
  • Zadanie: żądania w pętli
  • Asercje
  • Serializacja i deserializacja
  • Zadanie: serializacja i deserializacja
  • Organizacja projektu testowego
  • Zadanie: organizacja projektu testowego

Footer

Elzbieta Natalia Sadel
Calle Marzo 9 1 D
41009 Sevilla
Hiszpania
NIF: Y7882076J

Zostań trenerem!

Regulamin
Polityka prywatności
Polityka wsparcia w ramach członkostwa

Koszulki i torby dla testerów

Pomoc
Kontakt

Poskładane z 💛 przez Automatela.pl

Ta strona korzysta z ciasteczek aby świadczyć usługi na najwyższym poziomie. Dalsze korzystanie ze strony oznacza, że zgadzasz się na ich użycie.ZgodaNie wyrażam zgodyPolityka prywatności