Wprowadzenie

Na blogu pojawiło się kilka różnych artykułów dotyczących tego, jak wykorzystać Postmana do testowania WebApi. W tym artykule pokażę, w jaki sposób przyśpieszyć dodawanie żądań do Postmana, szczególnie w sytuacji, gdy zaczynamy używać Postmana z już istniejącym WebApi. Wykorzystamy do tego opisywaną już na blogu bibliotekę Swagger, która dokumentuje nasze API. Postman jest w stanie zaimportować taki opis i na podstawie tego wygenerować żądania do nowej kolekcji.

Import definicji WebApi

Jeśli to tej pory nie korzystałeś ze Swaggera, to proponuję przejrzeć wcześniejszy artykuł o nim − Swagger − dokumentowanie WebApi. W dalszej części artykułu zakładam, że jesteś zaznajomiony z tą biblioteką i umiesz ją dodać do projektu.

Do pracy nad artykułem wykorzystałem ten sam przykład z pozostałych wpisów o Postmanie, w którym aplikacja zawiera proste akcje do zarządzania produktami.

Po dodaniu Swaggera do aplikacji mamy adres w stylu http://localhost:60263/swagger/docs/v1, pod którym znajduje się opis naszego WebApi. Postman jest w stanie zaimportować taki opis, korzystając tylko z adresu url. Ewentualnie możemy wkleić cały opis do Postmana.

Aby zaimportować WebApi, wystarczy skorzystać z przycisku Import (punkt 1). Następnie przechodzimy do zakładki Import From Link (lub Paste Raw Test, gdy chcemy wkleić definicję WebApi) − punkt 2. W polu (punkt 3) wklejamy link i klikamy w przycisk Import (punkt 4):

W kolejnym kroku Postman zada nam dwa pytania:

• Czy zaimportować definicję jako API? − ten temat postaram się poruszyć w przyszłości na blogu.
• Czy utworzyć kolekcję z żądaniami dla WebApi? − czyli to, co nas interesuje.

Po potwierdzeniu operacji w Postmanie zobaczymy nową kolekcję, w której będą się znajdowały żądania dla poszczególnych akcji z WebApi:

Wygenerowane żądania są wrzucane do folderów na podstawie adresów akcji. Dzięki temu otrzymujemy ładną strukturę folderów w kolekcji, po której łatwo się nawiguje.

Jak widać na powyższym zrzucie, Postman podczas importowania API dodaje nową zmienną do środowiska (baseUrl), którą następnie wykorzystuje w adresach wygenerowanych żądań. Dzięki temu później możemy łatwo przełączać się między środowiskami.

Mając tak zaimportowane WebApi, możemy później modyfikować żądania. Kopiować, zmieniać, dodawać testy i tak dalej. Ogólnie pracować tak, jakbyśmy wszystko dodali ręcznie.

Gdzie jest json?

Przy domyślnej konfiguracji projektu możemy zauważyć, że po zaimportowaniu WebApi pozostaje jeden dość uciążliwy problem. Widać to na przykład na żądaniu, które dodaje nowy produkt do aplikacji:

Widzimy, że Postman w takiej konfiguracji w ciele żądania wygenerował pola w formie klucz−wartość, a nie w formie obiektu jsona − jak byśmy chcieli. Przez to później praca z takim żądaniem jest trochę bardziej problematyczna.

Dzieje się tak, ponieważ w opisie naszego api mamy informację, że ta akcja jest w stanie obsłużyć typ zawartości „application/x-www-form-urlencoded” :

Postman w takiej sytuacji korzysta z tego formatu, mimo że na pierwszym miejscu w definicji WebApi mówimy, że wspiera również jsona.

Na szczęście możemy to łatwo zmienić, lecz niestety nie robi się tego w samej konfiguracji Swaggera, tylko w samym WebApi. Wystarczy w pliku WebApiConfig w folderze App_Start wyczyścić listę dostępnych formaterów i dodać tylko formater dla jsona (linijka 6-7):

Po tak zmienionej konfiguracji Postman w ciele żądania ładnie wrzuci nam jsona:

W zależności od potrzeb te dwie linijki mogą być wykonywane zawsze w aplikacji lub tylko w momencie importowania żądań do Postmana.

Przykład

Na potrzeby tego wpisu wykorzystałem projekt z repozytorium https://github.com/danielplawgo/WebApiTests. Przykład znajduje się w branch swagger. Po jego pobraniu należy ustawić connection stringa w web.config.

Podsumowanie

Jak już wspominałem, obecnie nie wyobrażam sobie testowania WebApi bez Postmana. Dzięki niemu jestem w stanie szybciej i skuteczniej rozwijać WebApi. Szczególnie przydatna jest możliwość importu żądań do Postmana z użyciem Swaggera, zmniejsza ona ilość ręcznej pracy.