Ostatnio w pracy natknęłam się na problem. Miałam wysłać zapytanie GraphQL z różnymi parametrami, w celu sprawdzenia, czy jest zwracana odpowiednia odpowiedź (lista z jednym elementem). W sumie miałam do wysłania około 200 requestów. Robić to na piechotę? Nie było szans. Więc zerknęłam, co umożliwia nam stary dobry Postman.

Postman – Collections

Kiedyś w ramach generalnych porządków w historii requestów stwierdziłam, że czas pozapisywać część kluczowych endpointów w sekcji Collections, żeby nie szukać ich w historii. 

Każda z pozycji w kolekcji może zawierać listę zapytań:

Przyjrzyjmy się mojemu zapytaniu GraphQL:

Jak widać jest to jakieś testowe query, które przyjmuje 2 parametry (variable1 i variable2). Co ciekawe, wartości tych zmiennych to nie są zwykłe stringi. Zastosowałam binding – posiadam plik, który zawiera listę obiektów złożonych z tych parametrów. Na podstawie nazwy parametru zostanie wybrana (zbindowana) wartość parametru dla każdej iteracji naszego zapytana.

Do automatyzacji procesu (weryfikacji, czy odpowiedź zawiera oczekiwany jeden element w liście items) potrzebny jest prosty test, który zdefiniowałam w zakładce Tests:

Skoro mamy przygotowany plik z parametrami, konkretne zapytania oraz test, możemy przejść do ostatniego etapu:

Po kliknięciu Run otwiera się w nowym oknie Collection Runner. Wybieramy w nim interesujący nas endpoint, ładujemy plik z parametrami (automatycznie wyświetla się na ich podstawie liczba iteracji), wybieramy interesujące nas opcje dotyczące np. zapisu odpowiedzi i puszczamy kolekcję naszych testów:

189 zapytań chwilę zajmuje – po ich zakończeniu widzimy wynik:

Możemy nawet podejrzeć szczegóły zapytania i odpowiedzi klikając w nazwę iteracji (w moim przypadku słowo test):

Podsumowanie

Funkcjonalność Collection Runner i testy w Postmanie to coś nowego dla mnie, ale jak widać – bardzo przydatnego. W dosyć prosty sposób można zaoszczędzić sporo czasu.