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

 

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