Postman to niewątpliwie najpopularniejsze narzędzie do testowania API wśród testerów i programistów. Jego intuicyjny interfejs i bogactwo funkcjonalności sprawiły, że stał się de facto standardem w branży, a umiejętność obsługi Postmana znalazła się wśród podstawowych wymagań w ofertach pracy dla specjalistów QA. Jednak, wraz z rozwojem projektów, rosnącymi wymaganiami, a także ostatnimi zmianami w samym Postmanie, wielu specjalistów zaczyna dostrzegać ograniczenia tego narzędzia.
Dlaczego powinieneś rozważyć inne narzędzia przed rozpoczęciem testów API?
1. Postman wprowadził wymóg logowania i synchronizację testów w chmurze
Dziś, aby tworzyć i importować kolekcje oraz korzystać ze środowisk, Postman wymaga pracy na koncie (w chmurze Postmana). Bez logowania działa tylko lightweight API Client – pozwala wysyłać żądania lokalnie, ale nie pozwala na zapis kolekcji.
To oznacza, że wszystkie Twoje testy (kolekcje, requesty, środowiska) są przechowywane w chmurze. Istnieje możliwość zapisywania danych wrażliwych w usłudze Postman Vault, ale i tak wielu specjalistów podchodzi z rezerwą do faktu synchronizacji danych w chmurze Postmana, ponieważ nie mają kontroli nad tym, gdzie przechowywane są ich testy.
2. Istnieją ograniczenia współpracy w darmowej wersji Postmana
W darmowym planie Postmana, zespół może liczyć maksymalnie 3 użytkowników. Każdy użytkownik ma do dyspozycji 25 uruchomień Collection Runnera miesięcznie (ale po jego wyczerpaniu wciąż możesz uruchamiać kolekcje z command line’a np. Newman / Postman CLI).
Wersje płatne Postmana dają „trochę więcej” – przede wszystkim zdejmują limit 3 użytkowników w ramach jednego zespołu, no ale mówiąc wprost – trzeba zapłacić.
3. Postman jest super… dopóki nie pracuje się z dużym zestawem testów
Postman jest narzędziem UI-first – czyli wszystko „wyklikuje” się w intefejsie graficznym aplikacji. Jest to bardzo wygodne, kiedy pracujemy na niewielkim zbiorze testów, lub np. po prostu debugujemy jeden endpoint. W przypadku większych projektów, logika testów jest rozproszona po requestach, a masowe zmiany i refaktoryzacje są trudniejsze. Utrzymanie testów potrafi być uciążliwe i czasochłonne.
W takim razie, jakie jest jest najlepsze narzędzie do testowania API?
Nie ma jednego „najlepszego” narzędzia do testowania API, ale w większości przypadków mocno rekomenduję zespołom, by od początku pisały testy API we frameworku umożliwiającym ich automatyzację, np. w Rest Assured lub Playwright.
Jakie korzyści niesie za sobą ten wybór?
- kod testów jest zintegrowany z systemem kontroli wersji (Git), co umożliwia posiadanie pełnej historii, śledzenie zmian i wykonywanie code review
- takie testy są łatwiejsze w rozwijaniu i utrzymaniu – mogą używać wspólnych funkcji i konfiguracji. Jedna zmiana nie wymaga od Ciebie przeklikania wielkiego zbioru kolekcji w Postmanie, a najpewniej zmianę w jednym miejscu w kodzie
- możesz wpiąć kod testów do CI/CD – czyli testy mogą być automatycznie uruchamiane przy każdym merge’u, deploy’u lub zgodnie z harmonogramem.
- takie testy są elastyczne – różne zestawy testów można uruchamiać w różnych momentach (np. smoke testy po deploy, testy regresji w nocy) bez ręcznej konfiguracji. Istnieje możliwość kategoryzacji testów np. po tagach i uruchamiania jedynie scenariuszy oznaczone danym tagiem (np. @auth, @payment itp.)
- testy mogą być parametryzowane i zasilane różnymi zestawami danych bez dublowania samych testów
- lepsze debugowanie i diagnostyka problemów – w kodzie możesz szczegółowo logować i debugować błędy
- brak uzależnienia od jednego dostawcy narzędzi (a w szczególności od cennika danego narzędzia), co daje komfort przy planowaniu długoterminowej strategii testowej
- dowolność wyboru systemu raportowania testów – masz możliwość dowolnego sposobu prezentacji wyników testów i integracji z wieloma narzędziami dedykowanymi generowaniu (jak np. Allure)
Gdzie mogą pojawić się trudności?
Pisanie testów automatycznych API wymaga przynajmniej podstawowych umiejętności programowania i znajomości danego frameworka. Niezależnie od tego, czy wybierzesz Rest Assured, Playwright czy inne narzędzie, próg wejścia jest tutaj zdecydowanie wyższy niż w przypadku Postmana. W zespole QA może nie być osób z takimi umiejętnościami, lub może zaistnieć potrzeba ich przeszkolenia.
Co jednak, jeśli z różnych przyczyn potrzebujesz narzędzia z interfejsem graficznym?
Postman to wciąż dobre narzędzie o ugruntowanej pozycji na rynku i aktywnej społeczności. Jeśli nie przeszkadza Ci wymóg logowania, synchronizacja w chmurze i limit 3 użytkowników w darmowej wersji, może być wciąż sensownym wyborem.
Jeśli jednak szukasz alternatywy dla Postmana, to istnieją narzędzia o zbliżonej funkcjonalności, polecane przez społeczność QA:
- Insomnia – sporadycznie z niej korzystam i polecam. Lekkie, szybkie narzędzie z możliwością pracy offline
- Bruno – patrząc po dyskusjach na Reddicie, „uciekło” tam sporo użytkowników Postmana. To całkowicie darmowe narzędzie open-source, które przechowuje kolekcje lokalnie jako pliki tekstowe
