Blog

Testowanie REST API nie różni się szczególnie od testów tradycyjnych aplikacji. Do dyspozycji mamy testy manualne i automatyczne. Zanim jednak przejdziemy do rodzajów testów, warto zastanowić się, od czego tak naprawdę powinniśmy zacząć?

Od czego zacząć testowanie api?

Przede wszystkim warto wiedzieć, czym jest API. Przeczytasz o tym w tym wpisie: Dlaczego świat nie przetrwa bez api?

Następna kwestia to zapoznanie się z dokumentacją, którą każde dobre API powinno mieć. To taki odpowiednik instrukcji obsługi. Ja wiem, że prawdziwy twardziel nie potrzebuje instrukcji, ale uwierz, że w tym przypadku to absolutna podstawa! Jeśli nie wiesz, na jakich zasobach operuje API, to nie ruszysz z miejsca. Poznanie endpointów i metod udostępniania API to konieczność. Dopiero gdy masz już tę wiedzę, możesz przystąpić do testów.

Wybór narzędzia do testowania

W tym miejscu pojawia się kolejna przeszkoda. Aby rozpocząć testy, potrzebujemy klienta, który nam to umożliwi. Tak naprawdę ich wybór jest ogromny, ale żeby oszczędzić Ci czasu na szukanie, rekomenduję Postmana. Niczym szczególnym się nie wyróżnia, ale ma wszystko, czego Ci trzeba. Do tego w mig znajdziesz masę poradników tłumaczących jak go obsłużyć.

Gdy już wybraliśmy narzędzie i zapoznaliśmy się z instrukcją REST API, w końcu możemy przejść do konkretów.

Kody odpowiedzi serwera

Na początek warto zwrócić uwagę, czy API używa poprawnych metod HTTP. Dla przykładu pobieranie listy produktów w sklepie nie powinno odbywać się żadną inną metodą niż GET.

O tym, czy dana akcja kończy się poprawnie, powiedzą nam kody odpowiedzi serwera.

Jakich kodów odpowiedzi serwera możesz się spodziewać i co one oznaczają?

• 2xx - operacja zakończona sukcesem
• 4xx - błąd zapytania (po stronie klienta)
• 5xx - błąd API

Ten ostatni typ błędów jest bardzo niepokojący, bo oznacza on, że coś jest nie tak z API, np. walidacja nie została zaimplementowana prawidłowo.

Natomiast błędy z serii 4xx to pożądana reakcja w przypadku, gdy klient wyśle zapytanie o parametrach innych, niż przewiduje dokumentacja.

Monkey testing

W wychwytywaniu błędów znakomicie sprawdza się tzw. Monkey Testing.

Tester ma tu za zadanie puścić wodze fantazji i losowo wprowadzać najróżniejsze dane, nazwy parametrów czy typy danych. Krótko mówiąc, jego działanie ma symulować oddanie telefonu w ręce małpy, która będzie na oślep klikać po aplikacji.

Dopóki otrzymujemy odpowiedź 4xx, czyli błąd klienta, a nie 5xx, czyli błąd twórców API, możemy przybić sobie piąteczkę, bo oznacza to, że jest dobrze!

Przy okazji ciekawostka. Może Cię to zdziwi, ale programiści lubią czasem płatać figle użytkownikom i ukrywać w kodzie zaskakujące smaczki. Przykładem może być błąd 418, który wskazuje, że… serwer odmawia parzenia kawy, bo jest czajnikiem. :D

Jest to nawiązanie do żartu prima aprillisowego z 1 kwietnia 1998 roku, kiedy to wypuszczono Hipertekstowy protokół kontroli ekspresu do kawy.

Behavior driven development

Powyżej opisane testy manualne testowały jedynie fragment procesu.

Kolejnym krokiem mogą być testy BDD, czyli Behavior Driven Development. Polegają one na naśladowaniu zachowań użytkownika aplikacji i pozwalają przetestować cały proces.

Osobiście jest to mój ulubiony rodzaj testów. Dzięki nim szybko możemy wyłapać błędy w logice aplikacji.

Dla lepszego zrozumienia wytłumaczę Ci ten test na przykładzie dodawania produktu do koszyka.

Powinno wyglądać to tak:

• Etap 1 - Wyświetlenie listy produktów.
• Etap 2 - Wejście w szczegóły danego produktu (dla uproszczenia przyjmijmy, że nie można dodać produktu do koszyka z poziomu listy).
• Etap 3 - Po wejściu w szczegóły powinniśmy móc wybrać ilość zamawianego towaru i kliknąć przycisk "Dodaj do koszyka".
• Etap 4 - Po dodaniu produktów do koszyka, jego ilość w magazynie powinna zostać zablokowana.

Właśnie w ten sposób powinno pisać się testy BDD. Nie dość, że dają one nam pewność, że niczego nie pominęliśmy w logice działania aplikacji, to jeszcze są pisane językiem zrozumiałym dla osób z biznesu.

Pozostałe rodzaje testów

Testy opisane powyżej skupiają się na tym, czy aplikacja działa poprawnie. To oczywiście bardzo ważne, ale zanim wypuścimy aplikację w świat, warto także wiedzieć, jak aplikacja poradzi sobie z obciążeniem i jak zareaguje w przypadku awarii.

W tym pomogą nam testy wydajnościowe, wśród których możemy wyróżnić:

• Testy obciążeniowe - sprawdzają, jak aplikacja radzi sobie przy przewidywanym ruchu. Dzięki nim zidentyfikujemy wąskie gardła.
• Testy przeciążeniowe - weryfikują, jak aplikacja zachowa się przy ekstremalnych obciążeniach.
• Testy wytrzymałościowe - pozwalają upewnić się, że oprogramowanie będzie działać sprawnie z oczekiwanym obciążeniem przez długi czas.
• Testowanie skalowalności - określa, czy oprogramowanie skutecznie obsługuje rosnące obciążenia.
• Spikle testing - sprawdza reakcję na duże skoki obciążenia generowane przez użytkowników.

Jak widzisz, testów do wykonania jest całkiem sporo, ale są one bardzo ważne z perspektywy użytkownika końcowego. Im więcej błędów zostanie wyłapanych na tym etapie, tym mniej będzie problemów z oprogramowaniem już po jego wypuszczeniu.