Tworzenie SOAP Mock Service i dynamicznych odpowiedzi za pomocą Groovy w SoapUI

Czym jest SoapUI i jak krok po kroku utworzyć w nim projekt, na tworzeniu mock’ów skupię się w poniższym artykule, korzystając z SoapUI w wersji 5.5.0.

SoapUI, w ogólnym zarysie, to darmowe narzędzie wykorzystywane w głównej mierze do testowania usług internetowych, mające swoje zastosowanie w testach automatycznych (a co za tym idzie również w testach regresji i w testach wydajnościowych), testach funkcjonalnych, a nawet w szeregu testów bezpieczeństwa. Umożliwia również tworzenie mock’ów, czyli symulacji (naśladowania) działania określonego środowiska zewnętrznego na przykład w celu sprawdzenia, czy testowany przez nas moduł wykonuje operacje zgodnie z założeniami. Jest to bardzo przydatne w sytuacjach, gdy przykładowo nie mamy dostępu do zewnętrznych serwisów wykorzystywanych na środowisku klienckim, a niezbędne jest posiadanie „atrapy” takiego obiektu w celu rzetelnego przeprowadzenia testów. Właśnie na tworzeniu mock’ów skupię się w poniższym artykule, korzystając z SoapUI w wersji 5.5.0.

Utworzenie projektu w SoapUI

Na początku należy stworzyć projekt SOAP. Aby to zrobić, wybieramy pozycję File > New SOAP Project:

W wyświetlonym oknie musimy podać WSDL: Web Services Description Language – jest to język, który opisuje specyfikację usług sieciowych z wykorzystaniem formatu XML, w powyższym przykładzie musimy po prostu podać namiar na dokument WSDL. Aby to zrobić, podajemy link do takiego dokumentu lub wczytujemy fizyczny plik w formacie XML poprzez wybranie Browse…:

Po wczytaniu WSDL-a, nazwa projektu nadaje się sama (można ją zmienić). Krótko wspomnę o pozostałych dostępnych opcjach:

• Create Requests – SoapUI, podczas importowania, tworzy przykładowe żądania/zapytania dla każdej operacji
• Create TestSuite – tworzony jest zestaw testowy dla importowanego pliku WSDL
• Relative Paths – wszystkie ścieżki plików w projekcie będą przechowywane w jednym xml-u całego projektu

Na potrzeby artykułu pozostawiłem zaznaczoną jedynie pierwszą opcję. Po kliknięciu Ok utworzy się projekt wraz z przykładowym request’em jak na screenie poniżej:

Utworzenie SOAP Mock Service

W tym artykule zaprezentuję działanie mocka na dwóch przykładach: pierwszy, który wykorzystałem również w części dotyczącej tworzenia projektu w SoapUI, będzie sumował dwie liczby całkowite otrzymane w komunikacie żądania. Drugi – będzie wczytywał z pliku listę miejscowości i ich kodów GUS na podstawie wzorca nazwy podanego w request.

Aby utworzyć SOAP Mock Service należy kliknąć PPM na węzeł interfejsu WSDL i wybrać opcję Generate SOAP Mock Service:

Wyświetli się okno, gdzie można określić podstawową konfigurację naszego przyszłego mocka – Soap UI domyślnie uzupełnia poszczególne pola, więc jeżeli odpowiada nam ustawiony domyślnie port oraz ścieżka adresu URL można wybrać OK:

Pojawi się jeszcze okno z nazwą tworzonej przez nas usługi mock, którą można zmienić lub pozostawić domyślną. Po kliknięciu OK usługa jest utworzona. Już na tym etapie można ją uruchomić, a nawet sprawdzić jej działanie – poniżej podstawowy schemat testu takiej usługi z ponumerowanymi krokami, które należy wykonać:

Dynamiczny Response z mocka dzięki skryptowi Groovy

Jak widać na powyższym screenie, nasz mock odpowiada, ale w response dostajemy nadal pustą odpowiedź (znak zapytania). Oczywiście można to szybko zmienić: przykład WSDL-a z tego artykułu pozwala na sumowanie dwóch liczb całkowitych. W związku z tym, jeżeli chcemy ustawić stałą odpowiedź, wystarczy „wklikać” się w Response 1 w naszym mocku i w oknie odpowiedzi w sekcji DodawanieWynik ustawić 10. Wtedy za każdym razem, niezależnie, co wprowadzimy w request, otrzymamy 10, a nie za bardzo nam chodzi o to, żeby w wyniku dodawania 2+6 wynikiem było 10. W tym momencie pomocna okazuje się możliwość pisania skryptów w języku skryptowym Groovy, wzorowanym na składni Javy. Edytor do pisania kodu dostępny jest bezpośrednio w SoapUI na dwóch poziomach:

• na poziomie całego mocka, gdzie możemy określić skrypty wykonywane: na starcie mocka (Start Script), przy zakończeniu działania mocka (Stop Script; te dwie opcje przydatne są do otwierania lub zamykania obiektów współdzielonych, jak np. połączeń do baz danych), po otrzymaniu żądania (OnRequest Script — typowym zastosowaniem jest określenie niestandardowego zachowania usługi MockService) oraz po przetworzeniu żądania (AfterRequest Script — wykorzystywany do zbierania danych lub raportowania)

• na poziomie danej metody, gdzie określamy skrypty, które wykorzystane będą w response mocka i dzięki którym możliwe będzie zwrócenie właściwego wyniku. Właśnie na przykładach tego drugiego typu skryptów skupię się w artykule.

Chcąc zwracać prawidłowe wyniki z naszego przykładu dodawania liczb, musimy odwołać się bezpośrednio do liczb do zsumowania, które dostaniemy na wejściu (w request). Następnie po wykonaniu odpowiednich działań, wynik przekazujemy w zmiennej zdefiniowanej w response. Skrypt w Groovy’m będzie wyglądał jak poniżej:

Teraz po wpisaniu w request dwóch liczb całkowitych, w response zobaczymy prawidłowy wynik sumy:

Innym przykładem, który chciałbym zaprezentować, jest wczytanie listy miejscowości i ich kodów GUS na podstawie wzorca nazwy przekazanego w request. Jednak dodatkowym aspektem poruszonym w tym przykładzie jest to, że lista, z której będą pobierane będą dane do response, znajduje się w pliku xml i to z niego będziemy pobierać informacje:

Przykładowy wynik wywołania żądania:

Podsumowanie

Jak widać, SoapUI oferuje szereg możliwości do wykorzystania w tworzeniu różnego rodzaju mocków. Za pomocą języka Groovy możemy realizować skrypty wykonujące potrzebne dla nas operacje, które przekazują tylko te wyniki, których oczekujemy. Dodatkowym atutem języka Groovy jest to, że jego składnia bazuje na Javie, więc możemy również wykorzystać szereg funkcji z Javy przy tworzeniu skryptów. Oczywiście przedstawione tu przykłady są jedynie podstawami zastosowania Groovy w SoapUI, ale przede wszystkim chciałem pokazać, że odniesienie się do tego, co wysyłamy i odbieramy w SoapUI jest dość proste i wcale nie musimy ograniczać się tylko do stałych odpowiedzi „wklepanych z ręki” w response. Każdy komunikat ma oczywiście swoją specyfikację i stopień skomplikowania – tu też jest pełna dowolność w działaniu, np. możemy operować na plikach, jak to zostało przedstawione w drugim przykładzie. Mam nadzieję, że powyższe informacje okażą się przydatne dla osób, które zaczynają przygodę z SoapUI oraz dla tych, którzy już wcześniej mieli do czynienia z tym narzędziem.