Testowanie API: od czego zacząć. Przewodnik dla początkujących

Czas czytania: 12 minut

Testowanie API zaczyna się od nieprzyjemnej obserwacji: aplikacja, która wygląda dobrze na ekranie, potrafi w tym samym momencie zwracać błędne dane pod spodem. Interfejs pokazuje to, co zdążył pobrać, i ukrywa całą resztę. Testy API sprawdzają warstwę, w której naprawdę dzieje się logika systemu, zanim cokolwiek zobaczy użytkownik. Ten przewodnik jest dla osób, które słyszały, że warto zacząć od API, i chcą wiedzieć, co konkretnie się w nim sprawdza, jak wygląda pierwszy test i co robić dalej, żeby nie skończyć na klikaniu w jednym narzędziu.

Czym jest API i dlaczego testuje się je osobno

API to zestaw reguł, według których jeden program prosi drugi o dane albo o wykonanie operacji. Aplikacja mobilna banku nie przechowuje salda w telefonie: pyta o nie serwer i dostaje odpowiedź w ustalonym formacie. Sklep internetowy nie liczy sam kosztu przesyłki, tylko pyta o niego usługę kurierską. Każde takie pytanie i każda odpowiedź to miejsce, w którym coś może pójść nie tak, niezależnie od tego, jak wygląda przycisk na ekranie.

Testowanie na poziomie API ma trzy przewagi nad testowaniem wyłącznie przez interfejs. Po pierwsze, jest szybsze: żądanie i odpowiedź to ułamki sekundy, a przeklikanie tej samej ścieżki w przeglądarce to kilkadziesiąt sekund. Po drugie, jest stabilniejsze, bo interfejs zmienia się znacznie częściej niż kontrakt API, więc testy rzadziej psują się bez powodu. Po trzecie, daje precyzję: gdy test API zawiedzie, wiadomo, która operacja i który system odpowiadają za błąd, zamiast szukać go w całej ścieżce użytkownika.

Jest też powód, o którym mówi się rzadziej. Wiele systemów ma dziś kilka interfejsów naraz: aplikację webową, mobilną i integracje z partnerami. Wszystkie korzystają z tego samego API. Jeden dobry test API chroni trzy interfejsy jednocześnie, a trzy zestawy testów interfejsu nie zastąpią jednego testu warstwy, z której wszystkie korzystają.

Co konkretnie się sprawdza

Początkujący testerzy często zatrzymują się na pytaniu „czy odpowiedź przyszła”. To jest jeden z sześciu obszarów, i najmniej wartościowy, bo samo przyjście odpowiedzi nie mówi nic o jej poprawności.

Obszar	Pytanie testowe	Przykład błędu, który to wychwytuje
Kontrakt	Czy odpowiedź ma strukturę i typy zgodne z dokumentacją?	Cena wraca jako tekst zamiast liczby, więc aplikacja mobilna przestaje sortować
Poprawność danych	Czy wartości są prawdziwe, a nie tylko obecne?	Suma zamówienia nie uwzględnia rabatu, choć pole rabatu jest wypełnione
Kody odpowiedzi	Czy system sygnalizuje sytuację właściwym kodem?	Brak zasobu zwraca 200 z pustą treścią zamiast 404, więc klient nie wie, że czegoś nie ma
Obsługa błędów	Co się dzieje przy danych niepoprawnych, pustych i skrajnych?	Ujemna ilość w koszyku przechodzi walidację i tworzy zamówienie na minus
Uprawnienia	Czy użytkownik widzi tylko to, co do niego należy?	Podmiana identyfikatora w adresie pokazuje cudze dane
Czas odpowiedzi	Czy odpowiedź przychodzi w akceptowalnym czasie pod obciążeniem?	Lista produktów zwalnia z 200 milisekund do czterech sekund przy tysiącu pozycji

Źródło: opracowanie własne Quality Island, na podstawie typowych znalezisk z projektów testowych.

Obszar piąty, uprawnienia, wart jest osobnego zdania, bo to najczęściej pomijany element w testach początkujących, a jednocześnie najdroższy w skutkach. Sprawdzenie go nie wymaga wiedzy o bezpieczeństwie: wystarczą dwa konta testowe i próba sięgnięcia z jednego po zasób drugiego.

Pierwszy test krok po kroku

Najprostszy możliwy test API składa się z czterech czynności i nie wymaga pisania kodu. Poniższe kroki wykonuje się w dowolnym narzędziu do wysyłania żądań, najczęściej w Postmanie.

Cztery kroki pierwszego testu

01Wyślij żądanie. Wybierz metodę (najczęściej GET, czyli pobranie danych), wklej adres punktu końcowego i naciśnij wyślij. To wszystko, co jest potrzebne, żeby zobaczyć pierwszą odpowiedź.

02Przeczytaj odpowiedź. Interesują cię trzy rzeczy: kod odpowiedzi, treść i czas. Kod mówi, czy operacja się udała, treść zawiera dane, czas pokazuje, jak szybko serwer odpowiedział.

03Zamień obserwację w test. Dopisz warunek, który narzędzie sprawdzi za ciebie przy każdym uruchomieniu: kod ma być równy 200, pole z ceną ma istnieć i być liczbą, lista ma mieć co najmniej jeden element.

04Zbierz testy w kolekcję. Kolekcja to zestaw żądań uruchamianych jednym kliknięciem. Od tego momentu masz coś, co da się powtórzyć przed każdym wydaniem, a nie jednorazowe sprawdzenie.

Krok trzeci jest granicą między sprawdzaniem a testowaniem. Wysłanie żądania i obejrzenie odpowiedzi to sprawdzenie: działa raz, dla jednej osoby, i znika, gdy zamkniesz narzędzie. Dopisanie warunku zamienia to w test, który jutro wykona ktoś inny i który za miesiąc powie, że coś się zepsuło.

Poniższe nagranie pokazuje ten sam przebieg w praktyce, na żywym przykładzie.

Kody odpowiedzi, które trzeba znać na pamięć

Kod odpowiedzi to pierwsza informacja, jaką dostajesz z serwera, i najczęstsze źródło nieporozumień w zgłoszeniach błędów. Warto znać pięć grup i kilka konkretnych numerów.

Kod	Znaczenie	Co robi tester, gdy go zobaczy
200	Operacja się powiodła	Sprawdza treść odpowiedzi, bo poprawny kod nie oznacza poprawnych danych
201	Zasób został utworzony	Weryfikuje, czy utworzony obiekt naprawdę istnieje, osobnym zapytaniem
400	Błędne żądanie po stronie klienta	Sprawdza, czy komunikat mówi, co jest nie tak, i czy nie ujawnia zbyt wiele
401 i 403	Brak uwierzytelnienia oraz brak uprawnień	Sprawdza, czy system rozróżnia te dwie sytuacje, bo mylenie ich to typowy błąd
404	Zasób nie istnieje	Sprawdza, czy to naprawdę brak zasobu, a nie ukryty błąd uprawnień
500	Błąd po stronie serwera	Zgłasza zawsze, dołączając żądanie, które go wywołało, bo to defekt, nie pomyłka użytkownika

Źródło: opracowanie własne Quality Island na podstawie standardu HTTP.

Jak czytać dokumentację API, zanim napiszesz pierwszy test

Dokumentacja API jest dla testera tym, czym wymagania dla testów funkcjonalnych: źródłem oczekiwanego zachowania. Najczęściej ma postać pliku w formacie OpenAPI, dawniej znanym jako Swagger, który da się otworzyć w przeglądarce jako interaktywną stronę. Znajdziecie tam listę punktów końcowych, dozwolone metody, wymagane i opcjonalne parametry, przykładowe odpowiedzi oraz kody, które API może zwrócić.

Przy pierwszym czytaniu warto szukać czterech rzeczy. Które parametry są wymagane, bo to gotowa lista testów negatywnych: każdy wymagany parametr trzeba raz pominąć i sprawdzić, czy API odmówi w czytelny sposób. Jakie są typy i zakresy, bo to druga lista: wartość spoza zakresu, zły typ, pusty ciąg znaków. Jakie kody odpowiedzi są przewidziane, bo każdy z nich powinien dać się wywołać w teście, a te, których nie da się wywołać, są albo martwe, albo źle opisane. Czy operacja zmienia dane, bo to decyduje, czy test musi po sobie posprzątać.

Rozbieżność między dokumentacją a rzeczywistością jest przy tym równie wartościowym znaleziskiem co błąd w działaniu. Jeśli dokumentacja mówi, że pole jest opcjonalne, a API bez niego zwraca błąd, to zgłoszenie dotyczy jednego z dwóch: albo kodu, albo dokumentu. Rozstrzyga o tym zespół, nie tester, ale to tester jest jedyną osobą, która porównuje jedno z drugim, zanim zrobi to klient integrujący się z waszym systemem.

Pięć błędów, które popełnia prawie każdy na początku

Sprawdzanie samego kodu odpowiedzi. Test, który weryfikuje wyłącznie, czy przyszło 200, przejdzie także wtedy, gdy serwer zwróci pustą listę zamiast danych. Warunek na kod to początek, nie cały test.

Testowanie tylko ścieżki, która działa. Największa wartość testów API leży w danych, których nikt się nie spodziewa: pustych polach, wartościach ujemnych, zbyt długich tekstach, znakach specjalnych, brakującym parametrze. Ścieżkę poprawną sprawdzi za was pierwszy użytkownik.

Testy zależne od siebie nawzajem. Jeśli drugi test korzysta z obiektu utworzonego przez pierwszy, to awaria pierwszego przewraca cały zestaw, a wynik nie mówi już nic o systemie. Każdy test powinien sam przygotować sobie dane i po sobie posprzątać.

Twarde wpisywanie danych środowiska. Adres serwera, token i identyfikatory wpisane na sztywno w żądaniu powodują, że zestaw działa w jednym środowisku i w jednym dniu. Zmienne środowiskowe rozwiązują to w pięć minut i oszczędzają tygodnie poprawek.

Ignorowanie dokumentacji, także wtedy, gdy jest błędna. Rozbieżność między dokumentacją a zachowaniem API to zgłoszenie samo w sobie, nawet jeśli aplikacja działa. Ktoś, kto będzie integrował się z tym API za pół roku, zbuduje kod na dokumentacji, nie na waszej pamięci.

Od klikania do testów, które uruchamiają się same

Postman jest dobrym miejscem startu, bo pozwala zobaczyć żądanie i odpowiedź bez pisania kodu. Szczegółowo opisaliśmy to narzędzie w osobnym przewodniku: Postman: co to jest, do czego służy i jak go używać. Zatrzymanie się na nim jest jednak najczęstszym sufitem w tej ścieżce.

Kolejne dwa kroki wyglądają tak. Najpierw uruchomienie kolekcji poza narzędziem, czyli z wiersza poleceń, tak żeby te same testy mogły odpalić się automatycznie po każdej zmianie w kodzie. Pokazaliśmy to na przykładzie testów integracyjnych w tekście Postman: testy integracyjne i testy API. Potem przejście do biblioteki w języku programowania, na przykład Rest Assured w Javie, gdy testów jest na tyle dużo, że potrzebują struktury, wspólnych funkcji i przeglądu w repozytorium jak zwykły kod.

Nie każdy zespół musi przejść całą tę drogę. Decyzja o tym, co zautomatyzować, a co zostawić, jest osobnym rachunkiem, który opisaliśmy na Strefie QA w tekście o tym, co naprawdę opłaca się automatyzować, a co nie. Zasada praktyczna: automatyzujcie to, co będzie sprawdzane przy każdym wydaniu, a nie to, co najłatwiej się automatyzuje.

Nasza perspektywa

Testowanie API jest w Quality Island jedną z pierwszych rzeczy, których uczymy w projektach automatyzacji, i nie dlatego, że jest modne. Z ponad 450 000 testów automatycznych napisanych dla ponad 100 firm wynika prosta obserwacja: zestaw testów oparty na API starzeje się wolniej niż zestaw oparty na interfejsie, więc po roku wciąż działa, zamiast wymagać przepisania.

Druga obserwacja dotyczy początkujących. Najszybciej uczą się ci, którzy zaczynają od cudzego, działającego API, publicznie dostępnego, zamiast od systemu własnej firmy. Powód jest prozaiczny: w cudzym API nikt nie tłumaczy im, że „tak miało być”, więc uczą się czytać odpowiedź, a nie powtarzać opowieść o tym, jak system działa.

Trzecia jest dla osób, które planują karierę. Umiejętność testowania API jest dziś jedną z niewielu, które przenoszą się między branżami bez zmian: bank, sklep i system medyczny mają zupełnie różne interfejsy, ale ich API sprawdza się tymi samymi pytaniami z tabeli wyżej. To czyni z tej umiejętności dobrą inwestycję nawet wtedy, gdy nie wiadomo jeszcze, w jakim projekcie się wyląduje.

Co zabrać z tego artykułu

01Testy API są szybsze, stabilniejsze i precyzyjniejsze od testów interfejsu, a jeden test chroni wszystkie interfejsy korzystające z tej samej warstwy.

02Sprawdza się sześć obszarów: kontrakt, poprawność danych, kody odpowiedzi, obsługę błędów, uprawnienia i czas odpowiedzi.

03Granicą między sprawdzaniem a testowaniem jest dopisanie warunku, który narzędzie zweryfikuje za was przy każdym uruchomieniu.

04Poprawny kod odpowiedzi nie oznacza poprawnych danych. Test na samo 200 przejdzie też wtedy, gdy serwer zwróci pustkę.

05Uprawnienia sprawdza się dwoma kontami testowymi i nie wymaga to wiedzy o bezpieczeństwie, a wychwytuje najdroższe błędy.

06Postman to dobry start i częsty sufit. Kolejne kroki to uruchamianie kolekcji automatycznie, a potem biblioteka w języku programowania.

Jeśli chcecie przećwiczyć to z trenerem, na realnych przykładach i z informacją zwrotną do własnych testów, mamy na to szkolenie od podstaw.

Wprowadzenie do testowania API