Ale gdzie ten test? Czyli testy automatyczne aplikacji WWW. Część 3.

Ale gdzie ten test? Czyli testy automatyczne aplikacji WWW. Część 3.

Dotychczas przedstawiliśmy jak operować na podstawowych kontrolkach strony WWW. Potrzebujemy teraz narzędzia, które posłuży nam do uruchomienia napisanych przez nas testów, a na koniec wyświetli podsumowanie.

Dotychczas przedstawiliśmy jak operować na podstawowych kontrolkach strony WWW. Natomiast nikt nie będzie chciał ciągle obserwować czy jego automat wykonuje zaimplementowane przez niego kroki, ponieważ ze względu na jego szybkie działanie nie będzie możliwa jednoznaczna ocena czy dany komponent działa poprawnie czy też nie. Poza tym jest to po prostu nudne :). Dlatego też potrzebujemy narzędzia, które posłuży nam do uruchomienia napisanych przez nas testów, a na koniec wyświetli podsumowanie. Do tego celu wykorzystamy TestNG oraz przykłady z poprzedniego artykułu. Do dzieła!

Pierwszą rzeczą, jaką musimy poznać, są podstawowe adnotacje przy konkretnych metodach, które decydują o tym, co i kiedy powinno się uruchomić. I tak w przypadku TestNG będziemy mieli do czynienia z:

  • @BeforeClass – metoda z tą adnotacją będzie zawierała operacje, które mają być wykonane na samym wstępnie.
  • @AfterClass – w metodzie z tą adnotacją umieścimy operacje, które zostaną uruchomione po zakończeniu wszystkich testów.
  • @BeforeMethod – akcje zaimplementowane w metodzie z tą adnotacją będą wykonywane przed każdym, zdefiniowanym w klasie teście.
  • @AfterMethod – analogicznie, w metodzie z taką adnotacją umieścimy operacje wykonywane po każdym teście.
  • @Test – metoda z tą adnotacją będzie naszym faktycznym testem. Na przykład sprawdzenie porawnego działania kontrolki drag and drop.

Budowa testu

W budowie testów wykorzystamy wszystkie adnotacje poza @AfterClass.
Przed rozpocięcem testu będziemy chcieli wskazać lokalizację sterownika dla przeglądarki Chrome. Ten krok znajdzie się w metodzie z adnotacją @BeforeClass.
Następnie w metodzie z adnotacja @BeforeMethod umieścimy kroki odpowiadające za przygotowanie WebDrivera, ustawieniu maksymalnego oczekiwania na elementy, uruchomieniu przeglądarki oraz przejścia pod adres z przykładami. Chcemy aby przeglądarka była otwierana przed każdym pojedynczym testem. W naszym przypadku nie jest to koniecznie, natomiast gdy mamy do czynienia z dłuższymi testami, gdy jeden z nich się nie uda może zablokować możliwość poprawnego wykonania kolejnych. Stąd też zapewnienie “świeżego” startu dla każdego z nich.
W metodzie z adnotacja @AfterMethod będziemy zamykać przeglądarkę.
Naszym pierwszym testem będzie sprawdzenie czy poprawnie działa kontrolka drag and drop. Drugim testem będzie wybór opcji. Obie metody reprezentujące te dwa testy będą oznaczone adnotacją @Test.

Raport

Po uruchomieniu testów otrzymamy krótkie podsumowanie:

Widzimy tutaj która klasa została uruchomiona – w naszym przypadku TestNgExample. Następnie kolejne uruchomienia przeglądarki, a na koniec podsumowanie: ile testów zostało uruchomionych, ile z nich się nie powowiodło, ile wystąpiło błędów, czy jakieś testy zostały pominięte oraz łączny czas wykonania. Jednak to nie wszystko. TestNG dostarcza również bardziej kompleksowy raport, który domyślnie generowany jest w katalogu /target/surefire-reports/ naszego projektu. W nim zawarte będą szczegółowe informacje o poszczególnych testach oraz ewentualnych błędach. Na drugim zrzucie wyszczególnione są na przykład czasy wykonania dla poszczególnych testów. Można zauważyć, że czas ten jest inny niż ten w podsumowaniu powyżej. Różnica wynika z tego, że w kompleksowym raporcie wyszczególniony jest czas potrzeby na wykonanie jedynie tych kroków, które znajdują się w metodzie z adnotacją @Test. Czas potrzebny na uruchomienie przeglądarki i przejście pod wskazany adres URL nie jest już uwzględniony, ponieważ ta akcja wykonywana jest przed testem.

raport TestNG (1)

raport TestNG (2)

Parametryzacja testów

To jednak nadal nie wszystko. Adnotacje mogą przyjmować jeszcze różne parametry. Jest ich dość sporo więc skupimy się na jednym przykładzie, a do szczegółów odsyłam tutaj. Załóżmy, że chcielibyśmy uruchomić 2 testy w zadanej kolejności przy czym drugi z nich zostanie uruchomiony jeśli pierwszy zakończył się wynikiem pozytywnym. Wykorzystamy do tego dwa parametry: priority, wskazujący na kolejność – im niższa wartość tym wyższy priorytet oraz dependsOnMethods, gdzie wartością jest nazwa bądź nazwy metod, które muszą być wykonane wcześniej. Dla naszych dwóch testów będzie to wyglądało następująco:

Co dalej?

Dobra, już trochę się namnożyło tego kodu. Z każdym kolejnym testem będzie go jeszcze więcej stąd też przydałby się jakiś sprytny sposób, który pozwoli na łatwe zarządzanie WebElementami i różnymi operacjami na nich. Także w kolejnej części opowiemy o Page Objectach. Pomyślnego testowania!

author-image

Przemysław Górski

Automatyk testów aplikacji frontendowych. Obecnie odpowiedzialny za testy automatyczne aplikacji mobilnej jednego z największych banków w Polsce. Sympatyk technologii javowych. W wolnych chwilach szarpie struny gitary i bawi się muzyką.