• 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 12. Asercje

Strona główna > Kursy > Testy API w REST Assured > API w REST Assured 12. Asercje

Do tej pory we wszystkich lekcjach korzystaliśmy z asercji z JUnita. Dzisiaj poznasz asercje w REST Assured, pokażę Ci też w jakim przypadku nie będzie można ich użyć.

Dokumentacja do sklepu

Po poprawnym postawieniu aplikacji dokumentację do niej znajdziesz pod localhost/fakestore/dokumentacja/. Tam też znajdziesz np. klucze potrzebne do uwierzytelnienia.

 

Asercje w REST Assured

Lekcję zaczniemy od małych porządków. W pierwszej kolejności dodamy do POMa jednoznacznie wersje źródeł i budowanej aplikacji:

<properties>
   <maven.compiler.source>1.8</maven.compiler.source>
   <maven.compiler.target>1.8</maven.compiler.target>
</properties>

Klasa bazowa testów

W tej lekcji pojawi się także „klasa bazowa”, po której będą mogły dziedziczyć nasze klasy testowe. Dzięki temu będziemy bardziej zgodni z DRY (don’t repeat yourself) i wyciągniemy do niej te elementy, które powtarzamy w każdym teście albo w każdej klasie testowej. Kod tej klasy znajdziesz na samym dole tej lekcji.

Asercje

W tej lekcji stworzymy pierwszą klasę testową rozszerzającą naszą klasę bazową. Po co taki temat zapytacie? Przecież prawie od początku używamy asercji i testujemy prawidłowo. W rzeczy samej. Używamy jUnitowych asercji i jeśli z jakiegoś powodu to się dla Was sprawdza, to nie widzę powodu, żebyście mieli przestać.

Chciałbym natomiast dostarczyć Wam umiejętności korzystania z trzeciej „grupy kroków” wspieranych przez RestAssured, czyli .then().
Ważną zmianą, która następuje w momencie, w którym używamy .then() jest typ obiektu, jaki jest zwracany. Do tej pory zawsze działaliśmy na obiektach Response. Teraz, jeśli chcemy stworzyć obiekt, to musi on być typu ValidatableResponse.

Przykład od którego zaczniemy to będzie test failujący, spróbujemy zrobić coś takiego (zwróćcie szczególną uwagę od .then() ):

given()
       .port(80)
       .when()
       .get(productsEndpoint + "/393")
       .then()
       .assertThat()
       .statusCode(201);

Taki kod mimo nie odwoływania się bezpośrednio do jUnitowych asercji zwróci Assertion Error: java.lang.AssertionError: 1 expectation failed. Expected status code <201> but was <200>.

*Ważne: użycie assertThat() jest nieobowiązkowe. Możemy go pominąć i test zadziała dokładnie tak samo. Jeżeli wolimy zapis, który odpowiada notacji BDD rozumianej też przez osoby nietechniczne, to pewnie zdecydujecie się na używanie go zawsze. Podobnie jest z and() które umożliwia łączenie wielu asercji. Możemy and() zapisywać lub nie (a nawet w ramach jednego requestu czasami je zapisać, a czasami nie, choć nie polecam takiego niespójnego zapisu!).

Nie musimy się oczywiście ograniczać do statusCode, możemy odwołać się do dowolnego miejsca w responsie, np. do jego wartości:

.body("name", equalTo("Fuerteventura - Sotavento"))

Ale także do liczby elementów:

.body("related_ids.size()", equalTo(4))

Oczywiście możemy sprawdzać wiele więcej i zachęcam do obejrzenia chociażby tego, co Wasze IDE podpowiada po then().

*Ważne 2: używamy tu metody equalTo(). Jest to jest tak zwany Matcher dostarczany przez bibliotekę Hamcrest. Polecam o nim poczytać więcej i zobaczyć co jeszcze dostarcza w ramach pracy własnej.

Kiedy nie użyjemy asercji z REST Assured?

Czy REST Assured’owe asercje mogą całkowicie zastąpić te jUnitowe? Prawie. 

Jedyny przypadek, jaki mi zdarza się chcieć obsługiwać, a na który nie znalazłem w REST Assured wbudowanego sposobu, to sprawdzanie, że faktycznie rzucany jest wyjątek. 

Do tego celu nie dość, że musimy „wyjść” z REST Assured, to jeszcze najwygodniej użyć tzw. lambd. Ci z Was, którzy próbowali parsować JSONa przy pomocy xmlPath wiedzą, że nie kończy się to najlepiej. Tak powinno być i jeżeli chcielibyśmy zbudować asercję, która to potwierdzi, w JUnicie wyglądało by to tak:

Assertions.assertThrows(XmlPathException.class, () -> {
   validatableResponse.extract().xmlPath().get("test");
});

Tutaj sprawdzamy, że rzucony zostanie wyjątek „XmlPathException” wtedy gdy spróbujemy wykonać validatableResponse.extract().xmlPath().get(„test”);

Z mojego doświadczenia z lambdami jest jak ze wszystkim: wydają się dość logiczne, kiedy widzi się je napisane w kodzie, natomiast umiejętność praktycznego używania przychodzi z czasem i kolejnymi liniami napisanego kodu. Piszcie więc najlepiej oba rodzaje testów. To co się da sprawdzajcie w ramach ValidatableResponse, a szczególne przypadki (testy negatywne na przykład) w jUnitowych asercjach.

Kod

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ć.

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