{"id":2429,"date":"2016-04-20T10:55:31","date_gmt":"2016-04-20T08:55:31","guid":{"rendered":"https:\/\/sii.pl\/blog\/?p=2429"},"modified":"2023-08-18T10:02:13","modified_gmt":"2023-08-18T08:02:13","slug":"tworzenie-zewnetrznej-klasy-do-testow-soapui-v-2-zaawansowane-zastosowania","status":"publish","type":"post","link":"https:\/\/sii.pl\/blog\/tworzenie-zewnetrznej-klasy-do-testow-soapui-v-2-zaawansowane-zastosowania\/","title":{"rendered":"Tworzenie zewn\u0119trznej klasy do test\u00f3w SoapUI v. 2 \u2013 zaawansowane zastosowania"},"content":{"rendered":"\n

W ci\u0105gu ostatnich dw\u00f3ch artyku\u0142\u00f3w dowiedzieli\u015bcie si\u0119 ju\u017c w jaki spos\u00f3b napisa\u0107 fragment swojej klasy oraz na co nale\u017cy zwraca\u0107 szczeg\u00f3ln\u0105 uwag\u0119 podczas procesu jej projektowania. W tym, ostatnim, artykule tej serii porusz\u0119 tematy zwi\u0105zane z zaawansowanym zastosowaniem naszej klasy.<\/p>\n\n\n\n

Obawiam si\u0119, \u017ce ju\u017c w tym miejscu musimy troch\u0119 zmieni\u0107 nazewnictwo, de facto nie b\u0119dzie to ju\u017c tylko klasa, poniewa\u017c zaczyna si\u0119 ona ju\u017c zbli\u017ca\u0107 do bycia frameworkiem (narz\u0119dzie wspomagaj\u0105ce budow\u0119 danej aplikacji \u2013 w naszym przypadku projektu test\u00f3w SoapUI<\/a>)<\/strong>.<\/p>\n\n\n\n

Ten artyku\u0142 wymaga znajomo\u015bci Javy i programowania obiektowego na poziomie co najmniej dobrym \u2013 poniewa\u017c nie jestem w stanie zamie\u015bci\u0107 w nim ca\u0142ego opisu tworzenia element\u00f3w frameworka zamieszcz\u0119 tylko najwa\u017cniejsze fragmenty, kt\u00f3re postaram si\u0119 szczeg\u00f3\u0142owo om\u00f3wi\u0107.<\/p>\n\n\n\n

Na pocz\u0105tek zalecam uporz\u0105dkowa\u0107 troch\u0119 struktur\u0119 plik\u00f3w naszego frameworka.<\/p>\n\n\n\n

\"1\"<\/a><\/figure>\n\n\n\n

<\/p>\n\n\n\n

Jak pami\u0119tacie z pierwszego artyku\u0142u, mieli\u015bmy tam jedn\u0105 klas\u0119 nazywaj\u0105c\u0105 si\u0119 SoapHelper i za jej pomoc\u0105 uzupe\u0142niali\u015bmy 2 pola \u2013 has\u0142o i login. Na tym etapie zaleca si\u0119 podzieli\u0107 klasy na funkcjonalno\u015bci kt\u00f3re maj\u0105 spe\u0142nia\u0107<\/strong>, ja podzieli\u0142em je w nast\u0119puj\u0105cy spos\u00f3b:<\/p>\n\n\n\n

DataGenerator \u2013 tutaj umie\u015bci\u0142em 2 metody generuj\u0105ce odpowiednio login i has\u0142o<\/p>\n\n\n\n

FrameworkCore \u2013 zawiera wszystkie funkcjonalno\u015bci naszego frameworka wsp\u00f3lne dla wszystkich klas z kt\u00f3rych b\u0119dziemy korzysta\u0107.<\/p>\n\n\n\n

Dobrym przyk\u0142adem s\u0105 tu  \u201eSaveRavRequest\u201d i \u201eSaveRawResponse\u201d \u2013 przydatne przyk\u0142ady metod z kt\u00f3rych mo\u017cemy korzysta\u0107 podczas pisania test\u00f3w Soap \u2013 cz\u0119sto w momencie test\u00f3w interfejs\u00f3w, po zg\u0142oszeniu b\u0142\u0119du, programi\u015bci nas pytaj\u0105 o request i response, dzi\u0119ki tym metodom jeste\u015bmy w stanie je szybko wygenerowa\u0107 i mie\u0107 zapisane w pliku, kt\u00f3rego \u015bcie\u017cka jest okre\u015blona w core.properties, ich kod znajdziecie na screenie poni\u017cej.<\/strong><\/p>\n\n\n\n

RegistrationAssistant \u2013 klasa wykonuj\u0105ca ostateczn\u0105 cz\u0119\u015b\u0107 pracy, w niej znajduj\u0105 si\u0119 metody kt\u00f3re pomagaj\u0105 w testowaniu interfejsu do rejestracji. W tym przypadku s\u0105 tam tylko dwie metody \u201esetEmailProperty()\u201d oraz \u201esetLoginProperty()\u201d.<\/p>\n\n\n\n

Na screenie poni\u017cej zaprezentowa\u0142em to w jak najczytelniejszy spos\u00f3b:<\/p>\n\n\n\n

\"2\"<\/a><\/figure>\n\n\n\n

<\/p>\n\n\n\n

Jak pewnie zauwa\u017cyli\u015bcie widoczno\u015b\u0107 metod w klasie FrameworkCore jest ograniczona, wi\u0119kszo\u015b\u0107 z nich jest Protected, a to dlatego poniewa\u017c nie chcia\u0142bym \u017ceby ko\u0144cowy u\u017cytkownik frameworka u\u017cywa\u0142 ich w nieodpowiedni spos\u00f3b, chc\u0119 aby dost\u0119p do nich mia\u0142y tylko metody z klas z kt\u00f3rych b\u0119d\u0119 korzysta\u0107 w testach<\/strong> \u2013 takich jak RegistrationAssistant, za\u0142o\u017cy\u0142em \u017ce b\u0119d\u0105 one dziedziczy\u0107 po FrameworkCore.<\/p>\n\n\n\n

Przejd\u017amy teraz do tego jak dzia\u0142a pobieranie RawRequest i RawResponse, to nic innego jak parametry naszego kroku testowego, mo\u017cemy je pobra\u0107 w dok\u0142adnie taki sam spos\u00f3b w jaki uzupe\u0142niali\u015bmy Login i Has\u0142o:<\/p>\n\n\n\n

\"3\"<\/a><\/figure>\n\n\n\n

Te dwie metody zosta\u0142y skonstruowane w taki spos\u00f3b aby mog\u0142y by\u0107 u\u017cyte na ko\u0144cu ka\u017cdego testu. Zapisuj\u0105 requesty i responsey dla wszystkich krok\u00f3w danego scenariusza.<\/strong> Dlatego<\/strong> pierwsz\u0105 rzecz\u0105 na kt\u00f3r\u0105 zwr\u00f3ci\u0142em uwag\u0119 jest pobranie listy krok\u00f3w dla danego przypadku testowego, zamiast \u201egetTestStepList()\u201d mo\u017cna tutaj u\u017cy\u0107 innych metod takich jak \u201egetTestStepByName()\u201d lub \u201egetTestStepById()\u201d je\u015bli zale\u017ca\u0142oby nam tylko na tym aby pobrany by\u0142 konkretny krok testowy.<\/strong><\/p>\n\n\n\n

Drug\u0105 rzecz\u0105 z kolei jest to na co zwr\u00f3ci\u0142em uwag\u0119 ju\u017c wcze\u015bniej, pobranie requesta i responsea przebiega w podobny spos\u00f3b co ustawienie property \u201eLogin\u201d lub \u201eHas\u0142o\u201d (zamiast \u201esetPropertyValue()\u201d korzystamy z \u201egetPropertyValue()\u201d).<\/strong><\/p>\n\n\n\n

Przyjrzyjmy si\u0119 teraz jak to wygl\u0105da z perspektywy SoapUI. Po tym jak wejdziemy w nasz TestStep i jego CustomProperties wida\u0107 wyra\u017anie \u017ce mamy RawRequest, Request oraz Response.<\/p>\n\n\n\n

\"4\"<\/a><\/figure>\n\n\n\n

<\/p>\n\n\n\n

Zauwa\u017cyli\u015bcie \u017ce zaznaczy\u0142em na powy\u017cszym screenie 3 rzeczy:<\/p>\n\n\n\n

    \n
  1. RawRequest<\/li>\n\n\n\n
  2. Response<\/li>\n\n\n\n
  3. Request<\/li>\n<\/ol>\n\n\n\n

    Oznaczy\u0142em je g\u0142\u00f3wnie dlatego \u017ceby u\u015bwiadomi\u0107 wam gdzie one si\u0119 w SoapUI znajduj\u0105, tak \u017ceby\u015bcie byli w stanie je p\u00f3\u017aniej odnale\u017a\u0107 i wiedzie\u0107 sk\u0105d one s\u0105 pobierane. Zastanawiacie si\u0119 pewnie tak\u017ce dlaczego w kodzie pobra\u0142em akurat \u201eRawRequest\u201d zamiast wzi\u0105\u0107 \u201eRequest\u201d, sprawa jest ca\u0142kiem prosta \u2013 ot\u00f3\u017c \u201eRawRequest\u201d jest requestem z danymi kt\u00f3re faktycznie zosta\u0142y wys\u0142ane do aplikacji, a \u201eRequest\u201d nie ma rozwini\u0119tych parametr\u00f3w – co to znaczy?<\/strong><\/p>\n\n\n\n

    \"5\"<\/a><\/figure>\n\n\n\n

    <\/strong><\/p>\n\n\n\n

    To znaczy \u017ce zamiast danej kt\u00f3ra powinna zosta\u0107 pobrana z CustomProperty naszego TestCase\u2019a o nazwie Login, b\u0119dziemy mie\u0107 odno\u015bnik do tego pola, jak na ww. screenie.<\/strong><\/p>\n\n\n\n

    Teraz pytanie gdzie mo\u017cna skorzysta\u0107 z takich rzeczy jak generowanie danych \u2013 naturalnie i od razu przychodz\u0105 nam do g\u0142owy kroki groovy, ale to mocno zanieczyszcza projekt \u2013 dajmy na to:<\/p>\n\n\n\n

    200 przypadk\u00f3w testowych, ka\u017cdy z nich po oko\u0142o 5 krok\u00f3w to ju\u017c daje nam 1000 krok\u00f3w, a teraz dodajmy do tego jeszcze krok groovy na pocz\u0105tku i na ko\u0144cu, do tworzenia danych testowych i zapisywania wynik\u00f3w, i ju\u017c wyjdzie nam 1400 krok\u00f3w!<\/p>\n\n\n\n

    Na szcz\u0119\u015bcie nie trzeba tego robi\u0107, SoapUI oferuje nam doskona\u0142\u0105, wbudowan\u0105 mo\u017cliwo\u015b\u0107 dodawania skryptu pocz\u0105tkowego i ko\u0144cowego kt\u00f3re s\u0105 uruchamiane odpowiednio przed i po wykonaniu testu.<\/p>\n\n\n\n

    A mianowicie \u201eSetup Script\u201d i \u201eTearDown Script\u201d<\/strong>:<\/p>\n\n\n\n

    \"6\"<\/a><\/figure>\n\n\n\n

    <\/p>\n\n\n\n

    Setup Script przydaje si\u0119 je\u015bli nasz test musi mie\u0107 jakie\u015b warunki pocz\u0105tkowe, mamy tam dok\u0142adnie takie same mo\u017cliwo\u015bci jak w ka\u017cdym kroku skryptowym typu Groovy. Doradzam tworzenie tam mechanizm\u00f3w generuj\u0105cych \/ pobieraj\u0105cych dane testowe (jak na przyk\u0142ad \u201esetLoginProperty()\u201d i \u201esetEmailProperty()\u201d).<\/strong><\/p>\n\n\n\n

    TearDown Script natomiast jest doskona\u0142ym miejscem na wszystkie operacje ko\u0144cowe \u2013 takie jak logowanie czas\u00f3w wykona\u0144, usuwanie danych po te\u015bcie czy w\u0142a\u015bnie zapisywanie Request\u00f3w i Response\u00f3w (tak jak nasze \u201esaveRawRequests()\u201d oraz \u201esaveRawResponses()\u201d)<\/strong><\/p>\n\n\n\n

    \"7\"<\/a><\/figure>\n\n\n\n
    <\/div>\n\n\n\n
    \"8\"<\/a><\/figure>\n\n\n\n

    <\/p>\n\n\n\n

    Taki framework mo\u017ce umo\u017cliwi\u0107 nam bardzo du\u017c\u0105 ilo\u015b\u0107 funkcjonalno\u015bci z kt\u00f3rych nie mogliby\u015bmy skorzysta\u0107 z poziomu SoapUI:<\/p>\n\n\n\n