Webserwisy są popularne, Gumiś niedawno opisywał Postmana do testów REST, a tym razem przyszła kolej na drugie popularne narzędzie wykorzystywane do testów webserwisów. Można testować zarówno SOAP jak i REST.

Po włączeniu SoapUI widzimy ekran początkowy, ważne dla nas są aktualnie dwa przyciski.

1 Odpowiada za wczytanie projektu SOAP (2 odpowiednio REST, jednakże ten tutorial skupia się tylko na testach SOAP).

Potrzebujemy mieć WSDL serwisu, który chcemy testować. Przykładowe (działające) publiczne to:

http://www.thomas-bayer.com/axis2/services/BLZService?WSDL

Jest to serwis, który z kodów BLZ daje informacje o banku – wiele mi to nie mówi, ale na potrzeby tutoriala wystarczy 😉

Klikamy w ikonę SOAP i ukazuje nam się okienko.

W polu Initial WSDL wklejamy ‚wuesdeelkę’ (ew. używając Browse wybieramy z dysku, jeżeli mamy ściągnięty plik WSDL). Automatycznie wypełni się pole Project Name (które można zmienić, ale na potrzeby tego krótkiego opisu jest to zbędne).

Domyślnie zaznaczone jest Create Requests, można zaznaczyć też Create TestSuite, natomiast za chwilę pokażę, jak dodawać zestawy testów w projekcie. W Navigator widzimy nasz projekt z serwisami.

Klikając dwukrotnie na nazwę serwisu przy zielonych strzałkach otworzy się okienko właściwości

z którego możemy otrzymać podstawowe informacje a także zajrzeć w WSDL (tab WSDL Content).

Klikając w plusik przy nazwie usługi (getBank) pojawi się nam Request 1 – klikając dwukrotnie pojawi się okienko z wypełnionymi polami oraz tajemniczym znakiem zapytania. W pomarańczowym prostokącie zaznaczyłem miejsce, gdzie jest adres endpointa do którego strzelamy. Znak zapytania w zielonym prostokącie to miejsce, gdzie należy wprowadzić dane (jeżeli jest w pobliżu komentarz to poniższe pole można usunąć – jednak warto uważać na to i pilnować się dokumentacji, jeśli ją mamy). Niebieski prostokąt pokazuje, gdzie uruchamiamy strzał, natomiast żółty to miejsce, gdzie w razie potrzeb można zadeklarować autoryzację do webserwisu.

W Internetach znalazłem kod BLC jakiegoś banku z Berlina: https://bank-code.net/blz-sort-codes/10010111-DSK-Hyp-005361

uzupełniając i strzelając dostaniemy response.

Jak widać to bardzo proste i przyjazne narzędzie, otrzymujemy wynik a także w lewym dolnym rogu czas oczekiwania na odpowiedź. Aha, bardzo ważna sprawa – SoapUI zapisuje wszystkie nasze zmiany instant. Po zamknięciu okienka i otworzeniu go ponownie, pozostają wprowadzone dane.

Pora zrobić zestaw testów; taka dygresja – z angielskiego tłumacząc to zestaw testów, ale faktycznie jest to przypadek testowy lub może bardziej scenariusz testowy. Mimo to zachowam wierność tłumaczeniu.

Klikamy PPM na serwisie i wybieramy Generate Test Suite (możemy zostawić okienko z domyślnymi ustawieniami), a w kolejnym kroku nazwijmy nasz zestaw testów i przejdźmy dalej.

Dzięki ustawieniom domyślnym mamy wygenerowany zestaw z pierwszym przypadkiem testowym i krokiem.

Na nasze podstawowe potrzeby to wystarczająco, sprawdźmy co mamy w środku (double click na nazwie kroku getBank) – znajome okienko z requestem tak jak do usługi,

ale hola hola panie Holak, jak to lubił kiedyś mój chemik w LO mówić. Jest koło play magiczny przycisk plusa, co on może skrywać? Tam są asercje, jedna z najważniejszych rzeczy w testach – mówimy „Sprawdzam”. Dodajmy przykładową NotContains z ciągiem znaków ERROR ignorując ich wielkość.

Po dodaniu asercji wprowadźmy dane i wystartujmy test z błędnymi danymi – asercja daje FAILED a test jest na czerwono.

Ciekawostka, w navigatorze również ten krok testowy oznaczono na czerwono. Dzięki temu szybciej widzimy, gdzie się pojawiają problemy. OK, poprawmy dane i zobaczmy co się wydarzy.

Tym razem na zielono. Prosty test przygotowany.

Oczywiście można dodawać więcej kroków testowych (PPM na przypadku testowym – Add step) czy więcej zestawów testów (tu bardziej pasuje scenariuszy, ech…) do usługi. Również można więcej asercji dodać. Polecam poćwiczyć.

Można też tworzyć łatwo zaślepki – wybieramy Generate SOAP Mock Service,

w nowym okienku wybieramy czy chcemy utworzyć (create) czy edytować istniejącą zaślepkę. Możemy wybrać do jakiej usługi chcemy ją utworzyć, ścieżkę oraz port na jakim będzie. Przechodząc dalej otrzymujemy proste okienko z zaślepką.

Klikając dwukrotnie na usługę a potem powtarzając to na response możemy edytować odpowiedź. Można również dodawać ich więcej oraz umożliwić randomowość odpowiedzi. No ale to już zostawię do samodzielnej pracy. Dodajemy response i zamykamy.

Klikamy play. Pojawia się przycisk STOP oraz dwie zielone strzałki, gdy je klikniemy przeniesie nas do przeglądarki z otwartym tam WSDLem mocka. Warto skopiować ten adres, aby sprawdzić jak to działa. Mając go skopiowanego wchodzimy w request usługi, którą mockowaliśmy (przy cały czas włączonej zaślepce) i strzelamy. Dostajemy odpowiedź jaką sobie wpisaliśmy wcześniej. Niezależnie od tego jakie dane wprowadzimy. Ta prosta zaślepka odpowiada zawsze tak samo, niezależnie od requesta 🙂

Bardziej zaawansowane to już samodzielnie odkrywajcie. Zaślepkę można też wyeksportować do xmla – PPM na nazwie zaślepki i export.