W ciągu ostatnich dwóch artykułów dowiedzieliście się już w jaki sposób napisać fragment swojej klasy oraz na co należy zwracać szczególną uwagę podczas procesu jej projektowania. W tym, ostatnim, artykule tej serii poruszę tematy związane z zaawansowanym zastosowaniem naszej klasy.
Obawiam się, że już w tym miejscu musimy trochę zmienić nazewnictwo, de facto nie będzie to już tylko klasa, ponieważ zaczyna się ona już zbliżać do bycia frameworkiem (narzędzie wspomagające budowę danej aplikacji – w naszym przypadku projektu testów SoapUI).
Ten artykuł wymaga znajomości Javy i programowania obiektowego na poziomie co najmniej dobrym – ponieważ nie jestem w stanie zamieścić w nim całego opisu tworzenia elementów frameworka zamieszczę tylko najważniejsze fragmenty, które postaram się szczegółowo omówić.
Na początek zalecam uporządkować trochę strukturę plików naszego frameworka.
Jak pamiętacie z pierwszego artykułu, mieliśmy tam jedną klasę nazywającą się SoapHelper i za jej pomocą uzupełnialiśmy 2 pola – hasło i login. Na tym etapie zaleca się podzielić klasy na funkcjonalności które mają spełniać, ja podzieliłem je w następujący sposób:
DataGenerator – tutaj umieściłem 2 metody generujące odpowiednio login i hasło
FrameworkCore – zawiera wszystkie funkcjonalności naszego frameworka wspólne dla wszystkich klas z których będziemy korzystać.
Dobrym przykładem są tu „SaveRavRequest” i „SaveRawResponse” – przydatne przykłady metod z których możemy korzystać podczas pisania testów Soap – często w momencie testów interfejsów, po zgłoszeniu błędu, programiści nas pytają o request i response, dzięki tym metodom jesteśmy w stanie je szybko wygenerować i mieć zapisane w pliku, którego ścieżka jest określona w core.properties, ich kod znajdziecie na screenie poniżej.
RegistrationAssistant – klasa wykonująca ostateczną część pracy, w niej znajdują się metody które pomagają w testowaniu interfejsu do rejestracji. W tym przypadku są tam tylko dwie metody „setEmailProperty()” oraz „setLoginProperty()”.
Na screenie poniżej zaprezentowałem to w jak najczytelniejszy sposób:
Jak pewnie zauważyliście widoczność metod w klasie FrameworkCore jest ograniczona, większość z nich jest Protected, a to dlatego ponieważ nie chciałbym żeby końcowy użytkownik frameworka używał ich w nieodpowiedni sposób, chcę aby dostęp do nich miały tylko metody z klas z których będę korzystać w testach – takich jak RegistrationAssistant, założyłem że będą one dziedziczyć po FrameworkCore.
Przejdźmy teraz do tego jak działa pobieranie RawRequest i RawResponse, to nic innego jak parametry naszego kroku testowego, możemy je pobrać w dokładnie taki sam sposób w jaki uzupełnialiśmy Login i Hasło:
Te dwie metody zostały skonstruowane w taki sposób aby mogły być użyte na końcu każdego testu. Zapisują requesty i responsey dla wszystkich kroków danego scenariusza. Dlatego pierwszą rzeczą na którą zwróciłem uwagę jest pobranie listy kroków dla danego przypadku testowego, zamiast „getTestStepList()” można tutaj użyć innych metod takich jak „getTestStepByName()” lub „getTestStepById()” jeśli zależałoby nam tylko na tym aby pobrany był konkretny krok testowy.
Drugą rzeczą z kolei jest to na co zwróciłem uwagę już wcześniej, pobranie requesta i responsea przebiega w podobny sposób co ustawienie property „Login” lub „Hasło” (zamiast „setPropertyValue()” korzystamy z „getPropertyValue()”).
Przyjrzyjmy się teraz jak to wygląda z perspektywy SoapUI. Po tym jak wejdziemy w nasz TestStep i jego CustomProperties widać wyraźnie że mamy RawRequest, Request oraz Response.
Zauważyliście że zaznaczyłem na powyższym screenie 3 rzeczy:
- RawRequest
- Response
- Request
Oznaczyłem je głównie dlatego żeby uświadomić wam gdzie one się w SoapUI znajdują, tak żebyście byli w stanie je później odnaleźć i wiedzieć skąd one są pobierane. Zastanawiacie się pewnie także dlaczego w kodzie pobrałem akurat „RawRequest” zamiast wziąć „Request”, sprawa jest całkiem prosta – otóż „RawRequest” jest requestem z danymi które faktycznie zostały wysłane do aplikacji, a „Request” nie ma rozwiniętych parametrów – co to znaczy?
To znaczy że zamiast danej która powinna zostać pobrana z CustomProperty naszego TestCase’a o nazwie Login, będziemy mieć odnośnik do tego pola, jak na ww. screenie.
Teraz pytanie gdzie można skorzystać z takich rzeczy jak generowanie danych – naturalnie i od razu przychodzą nam do głowy kroki groovy, ale to mocno zanieczyszcza projekt – dajmy na to:
200 przypadków testowych, każdy z nich po około 5 kroków to już daje nam 1000 kroków, a teraz dodajmy do tego jeszcze krok groovy na początku i na końcu, do tworzenia danych testowych i zapisywania wyników, i już wyjdzie nam 1400 kroków!
Na szczęście nie trzeba tego robić, SoapUI oferuje nam doskonałą, wbudowaną możliwość dodawania skryptu początkowego i końcowego które są uruchamiane odpowiednio przed i po wykonaniu testu.
A mianowicie „Setup Script” i „TearDown Script”:
Setup Script przydaje się jeśli nasz test musi mieć jakieś warunki początkowe, mamy tam dokładnie takie same możliwości jak w każdym kroku skryptowym typu Groovy. Doradzam tworzenie tam mechanizmów generujących / pobierających dane testowe (jak na przykład „setLoginProperty()” i „setEmailProperty()”).
TearDown Script natomiast jest doskonałym miejscem na wszystkie operacje końcowe – takie jak logowanie czasów wykonań, usuwanie danych po teście czy właśnie zapisywanie Requestów i Responseów (tak jak nasze „saveRawRequests()” oraz „saveRawResponses()”)
Taki framework może umożliwić nam bardzo dużą ilość funkcjonalności z których nie moglibyśmy skorzystać z poziomu SoapUI:
- Zapisywanie danych testowych bezpośrednio w bazie
- Usuwanie danych testowych
- Możliwość dopisania własnego loggera do Jira / ALM / etc..
- Możliwość tworzenia własnego Raportera do testów
- Możliwość szybkiej edycji wszystkich kroków testowych (więcej w Tips’n’Tricks na końcu)
- Czytelność testów – minimalizacja pracy, minimalizacja powtarzalnego kodu
- Zwiększa łatwość w utrzymaniu projektu SoapUI
Tips’n’Tricks
Na koniec chciałem podać jeszcze 2 całkiem przydatne sztuczki które mogą wam czasem zaoszczędzić dni pracy podczas testowania oprogramowania:
- W poprzednim artykule podałem przykład w którym tester miał zedytować 240 przypadków testowych, i zaleciłem podejście z wykorzystaniem frameworka do edycji wszystkich asercji, oto jakby wyglądał przykładowy kod – który można uruchomić w dowolnym miejscu projektu soapUI:
- Należy także wspomnieć o tym, że projekt SoapUI zapisany na dysku to nic innego jak jeden gigantyczny XML, który ma całkowicie powtarzalną strukturę – w razie potrzeby można go edytować ręcznie np. w Notepad++ używając opcji „Zamień wszystkie wystąpienia”. Należy jednak pamiętać o tym, że najbezpieczniej wtedy jest zrobić sobie backup wcześniej. Ponadto jako XMLa z łatwością możemy go edytować używając choćby Dom4j.
Chcesz lepiej zrozumieć aplikacje i systemy, które testujesz? Dołącz do ModernTester, poznaj najpotrzebniejsze narzędzia, frameworki oraz języki programowania i ćwicz na specjalnie przygotowanych środowiskach testowych: Platforma e-learningowa ModernTester
Zostaw komentarz