Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Postman jako zestaw narzędzi dla API (nie tylko dla testera)

Radosław Zagórski Software Engineering Manager
Postman jest świetnym narzędziem do pracy z zespołem na wspólnych danych. Poznaj jego potencjał jako narzędzie dla API i oceń czy warto go wdrożyć u siebie.
Postman jako zestaw narzędzi dla API (nie tylko dla testera)

W dzisiejszym świecie niemal każda aplikacja używa zewnętrznego lub wewnętrznego API (Application Programming Interface). Jeżeli nie używa to za chwilę będzie musiała użyć. Od wyświetlania listy użytkowników, przez wysyłanie metryk czy pobieranie danych pogodowych. Praktycznie wszędzie można trafić na API.


Czym jest Postman?

Postman to jedno z wielu narzędzi, które umożliwia w prosty sposób wysyłanie zapytań do dowolnego API. Podobnie jak systemowy cURL, więc po co instalować? 

Pracując nad wieloma projektami, zazwyczaj zaangażowanych jest wiele osób. Od architekta, developera czy finalnie Quality Enginnera, który zazwyczaj szuka dziury w całym. Zdarza się również, że nasze API będzie publicznie używane, więc grono odbiorców powiększa się również do osób, które nie mają dostępu do kodu. Wtedy przydaje się zawsze aktualna dokumentacja (ale o tym za chwilę).


Narzędzie ułatwiają pracę

Najprostsze użycie Postman’a ogranicza się do dosyć czytelnego interfejsu graficznego, którego rozpoznanie zazwyczaj trwa kilka do kilkunastu minut. Można pracować i sprawdzać zapytania. Idąc dalej, odkrywamy, że można parametryzować adresy, elementy body i to wszystko w czytelnym interface. Tutaj jest spora wyższość nad terminalowym cURL’em.

Po kilkunastu zapytaniach postanawiamy utworzyć kolekcję. Wtedy niczym w menadżerze plików jesteśmy w stanie poukładać nasze zapytania nie dość, że w kolejności to w kategoriach. Wszystkie informacje dotyczące użytkownika mamy w jednym folderze, autoryzacja w drugim natomiast zarządzanie produktami w naszym eCommerce znajduje się we wspólnym folderze z zapytaniami frontowymi o listy produktów, ale tam… robimy kolejny folder i nadal jest porządek.

Nad projektem pracuje co najmniej kilka osób, a tester zawsze dopytuje o dokumentację albo o przykładowe zapytanie, bo coś nie gra i chciałby sprawdzić, czy coś on źle ustawia, czy dokumentacja jest znów nieaktualna. Zespołowo dosyć szybko odkrywamy Workspace w Postmanie, gdzie zespoły mogą w trybie rzeczywistym pracować na tych samych requestach i w prosty sposób ułatwiać swoją pracę. Przygotowałeś nowy endpoint API? To zapisz wspólnych workspace, żebym mógł też szybko zacząć na nim pracować.

Ale chwila! Przecież do testów mamy różne środowiska i chciałbym zmienić URL zapytania albo na każdym środowisku używamy innych kluczy do API systemy płatności. Nie będę wklejać za każdym razem nowych. Kolejny raz Postman wychodzi naprzeciw i umożliwia tworzenie środowisk z indywidualnymi zmiennymi. Jeżeli możemy się w tym wymieniać — to ustawiamy, jeżeli każdy developer/tester posiada swoje, to nie ma problemu, każdy raz ustawia własne lokalne zmienne i też działa.


Ale co z automatyzacją?

W trakcie developmentu jednego endpointu potrzebujemy wykonać kilka zapytań, żeby dojść do tego, co nas interesuje. Myślę, że znamy te kroki: autoryzacja, lista produktów, wyświetl 2 stronę, pobierz artykuł XYZ, zmień tytuł, sprawdź tytuł, wejdź w cennik… co najmniej kilka a czasami kilkanaście zapytań. Trochę to ciężkie, żeby robić za każdym razem kiedy zmieniamy jedną rzecz, ale nie ma wyjścia — trzeba poklikać. Postman udostępnia tutaj kilka wygodnych opcji. Pierwsze to testy wyniku zapytania każdy, kto zna podstawy JS, odnajdzie się testach. Do tego twórcy udostępnili wygodne API wraz z bazą przykładów, żeby jeszcze szybciej zacząć pisać swoje testy czy narzędzie automatyzujące np. pobieranie specyficznych danych z odpowiedzi i przekazywanie ich do kolejnego zapytania.

Przy dobrej konfiguracji możemy klikać w kolejne zapytania, a dane potrzebne do ich wywołania będą same się uzupełniać. Ale chwila ja mam klikać? W tym miejscu pomogą nam kolekcje. Każdą kolekcję można dowolnie automatycznie w całości wywołać. Do tego jest również możliwa zmiana kolejności przed wywołaniem. Proste? A jakie szybkie i funkcjonalne!

W jednym projekcie miałem potrzebę zasilenia danymi testowymi danych użytkowników. Proste zadanie. Tylko żeby mieć w miarę efektywny zbiór danych należało mieć 3000 losowych użytkowników. Postman ma wbudowany generator losowych (całkiem sensownych) danych. Jeżeli ktoś zna bibliotekę Faker dostępną dla różnych platform będzie wiedział, o co chodzi. Wystarczy odpowiednio ustawić losowe dane i uruchomić kolekcje 3000 razy (tak, wystarczy wpisać 3000 w odpowiednim polu).


Wróćmy do dokumentacji

Największym bólem jest pisanie dokumentacji, jeżeli już ją mamy to pojawia się kolejny jeszcze większy ból. Aktualizacja tej dokumentacji. Nie zawsze każdy pamięta, żeby zaktualizować ten dokument, jak wypadnie jeden parametr, to już prawdopodobnie nigdy tam nie trafi. Za kilka miesięcy ktoś może dostać zadanie “zaktualizuj dokumentację” i co wtedy…

Lepiej pomyślmy o tym wcześniej i twórzmy dokumentację w jakimś standardzie. Dla znających temat OpenAPI wybór jest naturalny. Tylko znów robimy dodatkowy dokument, który wygeneruje dokumentację albo używamy magicznej składni w kodzie, która nie zawsze jest wygodna i posiada wszystkie najnowsze możliwości danej specyfikacji.

Ale co gdybyśmy pisząc dokumentację, pisali od razu przykładowe zapytania i mogli tego użyć. Wszystko to w naszym workspace i dzielone praktycznie automatycznie z zespołem. Każda zmiana zaczyna się od aktualizacji dokumentacji, żeby mieć co weryfikować. Tak, Postman to umożliwia. Zawsze aktualna dokumentacja, aktualne przykładowe requesty i wszystko współdzielone wraz z testami i parametrami.

Warto dodać, że Postman również udostępnia tzw. Mock Servers, które przydają się kiedy jeszcze tych endpointów nie ma. Wtedy frontend może zacząć pracę, jak jeszcze nie ma stworzonej infrastruktury, kolejna zaleta.


Podsumowanie

Postman przez kilka ostatnich lat dosyć mocno się rozwinął. Z narzędzia, które było dostępne tylko jako rozszerzenie do przeglądarki, utworzony został niezależny ekosystem wspierający całą pracę nad API. W powyższym artykule nie wspomniałem o publikowaniu API publicznie, monitorowaniu czy Postman Flows do wizualizacji przepływów. Pracę można dodatkowo wzbogacić o pracę w trybie CLI i uruchamiania kolekcji bez GUI np. w naszych testach automatycznych używanych w Jenkinsie (narzędzie Newman).

Oczywiście nie każdy potrzebuje tak rozbudowanego narzędzie ale jeżeli już tego używamy, to może warto nauczyć się czegoś więcej?

Rozpocznij dyskusję

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej