7 rzeczy, które musisz WIEDZIEĆ zanim zaczniesz testować REST API

Już na samym początku muszę Cię ostrzec!

Istnieje wiele mitów na temat testowania backendu i osobiście słyszałem przynajmniej kilka. Niestety do tej pory nie wiem skąd się wzięły.

  • Testowanie REST API jest trudne
  • Testowanie REST API jest tylko dla programistów
  • Skąd mam wiedzieć co testuję skoro tego nie widzę i nie mogę w nic kliknąć
  • Do testowanie REST API używa się tylko SoapUI
  • Automatyzacja testów to Selenium!

Nie wierz w mity i dziwne obrazki z internetu!

Poniżej przygotowałem 7 rzeczy, które musisz wiedzieć zanim zaczniesz testować REST API, dodatkowo, na koniec, mam dla Ciebie dwa BONUSY!

To co zaczynamy?

1. Co to jest REST API?

REST czyli representational state transfer – jest to styl architektury, który wykorzystuje dobre praktyki, które powstały podczas tworzenia protokołu HTTP.

Uffff!!! Obiecuję, że to było najtrudniejsze zdanie w całym poście.

Generalnie musisz zapamiętać, że REST bazuje na protokole HTTP a co za tym idzie korzysta z metod HTTP takich jak GET, POST, PUT, DELETE oraz z kodów odpowiedzi takich jak 200 OK lub 201 CREATED itp. Do metod HTTP i kodów odpowiedzi zaraz wrócimy.

API czyli application programming interface – jest to interface (połączenie), który pozwala na komunikację między różnymi programami.

Jeżeli Ty chcesz się skomunikować z programem, to musisz użyć interfejsu użytkownika np: klawiatura, która pozwala Ci wpisać dane do programu.

Jeżeli dwa programy chcą się ze sobą skomunikować to używają właśnie API czyli interfejsu programistycznego.

Czyli REST API jest to interfejs programistyczny, który pozawala na komunikację między programami a dodatkowo używa rozwiązań z protokołu HTTP czyli metod HTTP czy kodów odpowiedzi.

2. Co to jest i z czego składa się request?

Request jest to zapytanie, które jeden program (aplikacja) wysyła do innego programu (serwera).

Wyobraź sobie stronę, na której możesz wyszukać loty z kilku lini lotniczych. Strona, czyli jeden program, po kolei wysyła zapytania do różnych serwerów np: LOT, RYANAIR, easyJet, Afganistan Airlines i pyta o loty z miejsca A do miejsca B w podanym czasie.

Każdy request składa się z kilku elementów:

a) metoda HTTP

b) endpoint czyli adres, na który request zostanie wysłany

c) czasami składa się też z danych, np do utworzenia danych (dokładnie tak samo jak dodawanie danych z formularza na stronie WWW)

3. Metody HTTP

Żeby zacząć testować REST API musisz znać te cztery metody:

GET – metoda służąca do odczytu danych

POST – metoda służąca do dodania danych

PUT – metoda służąca do edycji danych

DELETE – metoda służąca do usunięcia danych

4. Co to jest i z czego składa się response?

Response jest to odpowiedź, którą serwer zwraca do programu (aplikacji), która wysłała request.

Wracając do naszej wyszukiwarki lotów. Strona wysyła zapytanie o loty z Warszawy do Londynu w podanym okresie.

Serwer LOT zwraca odpowiedź z listą dostępnych lotów plus ilość miejsc plus ceny.

To samo robią serwery RYANAIR i easyJet.

Serwer Afganistan Airlines zwraca błąd: Warszawa – nieznana lokalizacja 😉

Każda odpowiedź składa się z kilku elementów:

a) dane zwracane w odpowiedzi – bardzo często w formacie JSON

b) kod odpowiedzi

Sprawdzając tylko kod odpowiedzi można natychmiast stwierdzić czy request został wysłany poprawnie czy wystąpiły jakieś problemy.

5. Kody odpowiedzi

Protokół HTTP definiuje pięć grup kodów odpowiedzi.

1xx (setki) – odpowiedzi informacyjne

2xx (dwusetki) – sukces

3xx (trzysetki) – przeniesienia / redirecty

4xx (czterysetki) – błąd po stronie klienta

5xx (pięćsetki) – błąd po stronie serwera

6. Popularne kody odpowiedzi

Do zapamiętania kodów odpowiedzi polecam stronę: https://http.cat/

200 OK – request został wysłany poprawnie

201 CREATED – zasób został stworzony

400 BAD REQUEST – błąd w zapytaniu

401 UNAUTHORIZED – brak autoryzacji

500 INTERNAL SERVER ERROR – generalny błąd po stronie serwera

7. Co to jest endpoint?

Endpoint jest to adres URL (URI), na który będziemy wysyłali request.

Możemy mieć stronę, która na głównej domenie wystawia frontend, czyli stronę WWW, natomiast na innym adresie wystawia REST API.

www.strona.pl – frontend (strona WWW)

www.api.strona.pl – backedn (REST API)

Jeżeli chcemy przeczytać listę wszystkich użytkowników to musimy wysłać request z metodą GET na endpoint www.api.strona.pl/users

Jeżeli chcemy przeczytać dane tylko jednego użytkownika to musimy wysłać request GET na endpoint www.api.strona.pl/users/:id

BONUS 1 – Praktyka

Zdecydowanie najlepiej uczy się przez praktykę, więc podsumowując to co pokazałem Ci do tej pory, napiszemy pierwszy test i przekonasz się, że testowanie REST API nie jest takie trudne.

W naszym przykładzie użyjemy serwisu reqres, który wystawia RESTowe API z testowymi danymi pod adresem https://reqres.in/

reqres.io

Do dyspozycji mamy kilka endpointów z różnymi metodami HTTP. W naszym teście chcemy przeczytać listę wszystkich użytkowników czyli musimy wysłać request GET na endpoint https://reqres.in/api/users

Jeżeli otworzymy ten adres w przeglądarce https://reqres.in/api/users?page=2, to dostaniemy odpowiedź w formacie JSON, ale jak widzisz taka odpowiedź nie jest przeznaczona do manualnego testowania. Ciężko powiedzieć ilu użytkowników dostajemy w odpowiedzi lub czy dane dla wybranego użytkownika są poprawne.

W takim razie do napisania testu użyjemy bardzo popularnego narzędzia do testowania REST API jakim jest Postman. Możesz go pobrać ze strony https://www.postman.com/downloads/

W pierwszej kolejności musimy wybrać metodę HTTP. Do odczytania danych oczywiście będzie to metoda GET. W postmanie metoda GET jest wybrana domyślnie. W drugim kroku podajemy adres (endpoint), do którego chcemy wysłać request. Ostatnim krokiem jest wysłanie requesu więc klikamy przycisk Send.

Jak na razie nic trudnego, prawda? Ok, to zobaczmy co się stało po wysłaniu requestu. Prawie natychmiast dostaliśmy response (odpowiedź) z serwera zawierającą listą użytkowników. JSON został ładnie sformatowany i już na pierwszy rzut oka dużo łatwiej go przeczytać. Zwróć też uwagę na to, że z każdą odpowiedzią dostajemy też response code (kod odpowiedzi). W naszej odpowiedzi dostaliśmy 200 OK, czyli request został wysłany poprawnie, ale to już wiesz 😉

Pierwszy request wysłany, dostaliśmy poprawną odpowiedź ale dalej nie mamy żadnych testów. Czas to zmienić!

Żeby dodać testy, które będą coś sprawdzały w naszej odpowiedzi musimy przejść do zakładki Tests. W zakładce Tests, po prawej stronie mamy listę snippetów czyli gotowych rozwiązań, których możemy użyć. Skorzystamy z jednego snippetu i sprawdzimy czy status code (kod odpowiedzi) jest równy 200. Wystarczy, że klikniesz na wybrany snippet a kod testu wygeneruje się automatycznie.

Dodamy jeszcze jeden test, który sprawdzi czy liczba użytkowników w odpowiedzi jest równa 6. Tym razem sami napiszemy kod testu … spokojnie, zaraz zobaczysz, że to nie takie straszne.

  1. W pierwszym kroku utworzymy zmienną i nazwiemy ją “response” dalej do naszej zmiennej przypiszemy całego JSONa z odpowiedzi.
  2. Kopiujemy pierwszy test i zmieniamy opis testu oraz to co jest w środku, czyli sprawdzenie.
  3. Odpowiedź (JSON), którą dostaliśmy posiada pole “data”, które jest listą. W tej liście zapisane są obiekty reprezentujące poszczególnych użytkowników.
  4. Odpowiedź powinna zawierać 6 użytkowników, więc sprawdzimy czy lista ma długość 6, czyli czy składa się z 6 użytkowników.

Dodajemy drugi test i ponownie wysyłamy request.

Jak widzisz na dole w zakładce “Test Results” wszystko jest na zielono czyli oba testy przeszły.

BRAWO! Właśnie, zupełnie od ZERA, napisaliśmy dwa testy do REST API.

Wcale nie było to takie trudne, prawda?

Dziękuję Ci za wytrwałość i, mam nadzieję, że udało mi się przekazać Ci odrobinę wiedzy.

PS. Jeżeli masz jakieś pytania, to chętnie odpowiem.