W tej lekcji napiszemy pierwszy test API ale już nie w Postmanie, a przy użyciu REST Assured.
Dokumentacja do sklepu
Po poprawnym postawieniu aplikacji dokumentację do niej znajdziesz pod localhost/fakestore/dokumentacja/. Tam też znajdziesz np. klucze potrzebne do uwierzytelnienia.
Error:java: error: release version 5 not supported
Jeżeli zobaczysz ten błąd w trakcie uruchamiania swojego testu, zajrzyj tutaj. Znajdziesz tam informacje jak rozwiązać ten problem.
Wersja Javy
W tej lekcji w zależności od tego której wersji Javy używasz, mogą się pojawić drobne rozbieżności w działaniu poniższej linijki:
System.out.println(response.jsonPath().get("name"));Może być konieczne zrobienie tego w poniższy sposób:
System.out.println((String) response.jsonPath().get("name"));Pierwszy test API: linki i materiały
OAuth
W tej lekcji poznamy kolejną metodę przekazywania danych do logowania, a mianowicie OAuth1. Jest to sposób autoryzacji, który poprzez haszowanie przesyłanych danych nadaje się do wykorzystania w nieszyfrowanej komunikacji po http (bez “s”). Rezygnujemy z korzystania z https w przypadku naszego sztuczno-sklepu, ze względu na problemy z certyfikatami przy lokalnym jego postawieniu. Użycie OAuth jest w naszym przypadku prostsze. Będzie to też doskonała okazja, żeby zobaczyć i użyć innych metod autoryzacyjnych.
Pierwszy test API
Po bardzo poważnej zmianie, jaką jest zmiana motywu Postmana na ciemny (!) wyślemy z niego zapytanie o konkretny produkt (pojedynczy obiekt). Z takim działającym testem przeniesiemy się już do kodu i przepiszemy go używając REST Assured.
Zaczniemy od stworzenia projektu mavenowego, dodania potrzebnych zależności, w tym także tych, które będą nam potrzebne do używania OAuth. Więcej o tym mówię w filmie. Stworzymy też nową klasę testową. Zainicjalizujemy tam pola klasy wartościami, z których skorzysta nasz pierwszy test API.
Odpowiedź
W teście stworzymy sobie obiekt klasy implementującej interfejs Response zwracany przez metodę get(). Poznacie (lub przypomnicie sobie) podejście BDD (Behavior-Driven Development), czyli gherkinową notację Given-When-Then. To jej będziemy używać do budowania obiektu. Na razie poprzestaniemy na przygotowaniu, czyli metodzie given() i akcji, czyli metodzie when(). Żeby test był testem dodam także prostą asercję sprawdzającą kod odpowiedzi. To czy sprawdzanie samego kodu odpowiedzi w testach jest wystarczające pozostawiam każdej i każdemu z Was do rozważenia we własnym sercu i umyśle. Na pewno pod uwagę trzeba wziąć przede wszystkim co chcemy testem sprawdzić.
W filmie pokazuję też jak pobierać informacje z naszego obiektu reprezentującego odpowiedź. Można pracować na całej odpowiedzi albo tylko na poszczególnych jej elementach. Którego podejścia będziecie użyć w prawdziwym życiu, to już zależy od Was. Standardowo zapytany o to, które jest lepsze odpowiem: to zależy.
Co poćwiczyć?
Zadaniem domowym jest zmiana tego co mamy. Spróbuj wywołać inne kody odpowiedzi, w tym kod 403. Pobaw się też trochę odpowiedzią z API, poćwicz trochę wyciąganie różnych informacji pojedynczo (tak jak zrobiłem to z „name” w filmie).
Pierwszy test API – kod
Ukryta treść
Nie masz aktywnej subskrypcji. Wykup subskrypcję albo zaloguj się, by móc zobaczyć pełną lekcję.
Komentarze
Nie masz aktywnej subskrypcji. Wykup subskrypcję albo zaloguj się, by móc komentować.