• 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 8. CRUD: wspólne elementy żądań

Strona główna > Kursy > Testy API w REST Assured > API w REST Assured 8. CRUD: wspólne elementy żądań

W tej lekcji zaczniemy pokrywać testami cały CRUD i zaczniemy od dwóch pierwszych literek tego akronimu. Pokażę Ci też jak poradzić sobie z powtarzalnymi, wspólnymi elementami żądań.

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: wspólne elementy żądań

CRUD jest podstawową sekwencją działań na obiektach (w naszym przypadku) web service’ów RESTowych. Akronim, który każdy tester pewnie mógłby sobie wytatuować. Utwórz, Odczytaj, Modyfikuj, Skasuj czyli polski CRUD to UOMS 😉 

Sprawdzenie tych atomowych czynności zapewnia nam, że podstawowe operacje na danych są obsługiwane w systemie. Bez nich prawdopodobnie nie udałoby się nic bardziej skomplikowanego. W przypadku API pokrycie ich jest szczególnie istotne, bo często na nich potrafi skończyć się logika danego webService’u. Ale pamiętajcie, że to nie tylko akcje są ważne, ale i to na jakich danych są wykonywane . To wybieranie i wymyślanie odpowiednich danych do testów API potrafi być największym testerskim wyzwaniem. 

Zanim jednak przejdziemy przez wszystkie literki UOMSa to obiecane wcześniej wyciągnięcie części wspólnej! 

Adnotacja BeforeAll

Wykorzystamy jUnitową adnotację @BeforeAll (czyli wykorzystamy metodę wykonywaną raz, przed wykonaniem testów) i w tak oznaczonej metodzie ustawimy po prostu wartości pól klasy RestAssured, które następnie będą wykorzystywane w każdym teście. 

Warte osobnego wspomnienia są pola baseURI i basePath. Jeśli chodzi o różnice pomiędzy URI a URL, to odsyłam do wikipedii, albo w ogóle do google.pl. Natomiast najprościej mogę to chyba wytłumaczyć w ten sposób, że pełny URL (taki pod jaki np. strzelamy w Postmanie) składa się z baseURI + basePath + konkretny_adres_aktualnego_zapytania. W naszym przypadku baseURI to po prostu “http://localhost”, basePath to „fakestore/wp-json/wc/v3”, a potrzebujemy do niego dopisać na przykład „products/393” – z takich trzech elementów powstał pełny URL. 

Do wyciąganych przez nas parametrów należą jeszcze port (tu mam nadzieję nie ma żadnych wątpliwości) i authentication – wystarczy przekopiować odpowiedni fragment z naszych dotychczasowych zapytań. 

W momencie, w którym wiemy, że pola te mają odpowiednie dla nas wartości, to nie musimy ich już podawać w naszych requestach. Dzięki temu z: 

Response response = given()
               .port(80)
               .auth()
               .oauth(username, password, "", "")

               .when()
               .get(url + productsEndpoint + "/" + productCreated);

Robi nam się:

Response response =
                when()
                .get(productsEndpoint + "/393");

Gdyż wszystkie elementy sekcji given zostały już wcześniej ustawione. 

Trochę inaczej jest w przypadku POSTa – tutaj ustawiamy dwa parametry, które pomijamy w GET, czyli contentType i body. Stąd w przypadku tej metody sekcja given się pojawi, jednak musimy w niej przekazać tylko brakujące elementy – czyli ponownie fragment kodu jest krótszy – no i zgodnie z DRY (don’t repeat yourself) nie mamy powtórzeń.

Reader Interactions

Komentarze

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

Komentarze

  1. Tomasz napisał

    2 maja, 2020 o 12:52 am

    Czy błędem jest wykorzystanie (albo niesie to ze sobą jakieś negatywne skutki?) w tym przypadku metody setup'ującej requesty z adnotacją @BeforeEach zamiast @BeforeAll? Wtedy metoda i zmienne w niej wykorzystywane nie muszą być statyczne.

    Odpowiedz
    • Kuba Rosiński napisał

      2 maja, 2020 o 11:33 am

      Hej,
      Błędem jako takim - pewnie nie. Ale będzi [...] CAŁOŚĆ KOMENTARZA WIDOCZNA DLA SUBSKRYBENTÓW.

      Odpowiedz
      • Tomasz napisał

        5 maja, 2020 o 12:46 am

        Tak jak mówisz przy 2 testach przy korzystaniu z metody z adnotacją @BeforeEach czas testu wyłożył się o sekundę, w sumie już zauważalnie, przy dużej ilości testów wyjdzie to słabo. Co do drugiej części Twojej odpowiedzi, to wychodząc trochę poza Twój kurs i łącząc go z Selenium Eli, myślę o rozwiązaniu, które przez API tworzy obiekt, który potem dalej testuję na froncie. W Selenium korzystam z @BeforeAll bo mam tam niestety testy zależne od siebie i utrzymuję instancję testów przez całą klasę, do której dodałbym teraz chętnie Rest Assured, a z obiektem z klasy WebDriver nie ma opcji na metody statyczne z tego co wyszło mi przy testowaniu tego pomysłu.

        Odpowiedz
        • Kuba Rosiński napisał

          5 maja, 2020 o 10:16 am

          Bardzo fajny pomysl, zeby laczyc testy frontu i AP [...] 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