Testy integracyjne

www.proskar.pl

Testy integracyjne

Warsztaty PROSKAR

www.proskar.pl

Plan prezentacji

1. Czym są testy integracyjne?

2. Przedstawienie frameworku Arquillian.

3. Implementacja testów integracyjnych Arquilliana wykonywanych na zdalnym serwerze WildFly.

4. Konfiguracja Arquilliana.

5. Przeprowadzanie testów integracyjnych.

www.proskar.pl 2 / 47

Czym są testy integracyjne?

• Testy integracyjne służą testowaniu integracji pomiędzy dwoma modułami aplikacji, bądź aplikacją a zewnętrzną usługą.

• Testy integracyjne powinny być uruchamiane na specjalnie przygotowywanym środowisku testowym, które maksymalnie odwzorowywałoby środowisko produkcyjne.

www.proskar.pl 3 / 47

Framework Arquillian

• Arquillian to framework do przeprowadzenia szeregu testów, również testów integracyjnych, w symulowanym środowisku produkcyjnym.

• Głównym celem, jest przygotowanie testowanego kodu do postaci archiwum i wykonanie testów na wybranym kontenerze aplikacyjnym, który może być obsługiwany w jednym z trzech trybów.

www.proskar.pl 4 / 47

Tryby kontenera aplikacyjnego

• Wbudowany (embedded) – Arquillian sam uruchomi proces kontenera aplikacji w tym samym środowisku, co uruchamiane testy. Po wykonaniu testów kontener zostanie wyłączony.

www.proskar.pl 5 / 47

Tryby kontenera aplikacyjnego

• Zarządzany (managed) – Arquillian uruchomi proces kontenera aplikacji jako oddzielny proces na oddzielnej instancji JVM. Po wykonaniu testów kontener zostanie wyłączony.

www.proskar.pl 6 / 47

Tryby kontenera aplikacyjnego

• Zdalny (remote) – Arquillian wymaga uruchomionej instancji kontenera pod adresem wskazanym w konfiguracji, aby móc wysłać testowany kod na serwer w celu wykonania testów, po czym odbiera wyniki ich wykonania. W tym trybie Arquillian w żaden sposób nie zarządza cyklem życia kontenera. Testowanie w tym trybie najlepiej symuluje środowisko produkcyjne.

www.proskar.pl 7 / 47

Schemat przeprowadzania testów

• Testowanie rozpoczyna się od uruchomienia metody statycznej oznaczonej adnotacją @Deployment, która dostarcza archiwum z testowanym środowiskiem.

• Wygenerowane przez autora testu archiwum wysyłane jest następnie do kontenera, gdzie wykonywane są testy w tej klasie a ich wynik jest odbierany po ich wykonaniu.

• Następnie po wykonaniu testów archiwum jest odłączane od kontenera.

www.proskar.pl 8 / 47

Schemat przeprowadzania testów

• Każdy plik testowy wymaga własnej adnotacji @Deployment i wiąże się z wygenerowaniem oddzielnego archiwum, które zostanie sekwencyjnie wdrożone na serwer testowy. W jednej chwili na raz testowana jest tylko jedna klasa.

www.proskar.pl 9 / 47

Implementacja testów integracyjnych Arquilliana wykonywanych na zdalnym

serwerze WildFly

www.proskar.pl 10 / 47

Wymagane zależności Maven

• Wszystkie zależności dodawane są w tagu <dependencyManagement> głównego POM'a, gdzie określa się wersje wszystkich komponentów. W plikach POM modułów definiuje się już tylko wymagane komponenty bez definiowania wersji. Dzięki takiemu podejściu modyfikacja wersji frameworka jest znacznie prostsza.

www.proskar.pl 11 / 47

Wymagane zależności Maven

• Podstawą Arquilliana jest BOM.

www.proskar.pl 12 / 47

Wymagane zależności Maven

• Wersjonowanie zależności można rozwiązać poprzez parametry definiowane w POM'ie, co dodatkowo pomoże uprościć zarządzanie wersjami. ${arquillian-version} zdefiniowany jest w części properties:

www.proskar.pl 13 / 47

Wymagane zależności Maven

• Kolejnym ważnym krokiem jest zdefiniowanie zależności do kontenera.

www.proskar.pl 14 / 47

Wymagane zależności Maven

• Aby móc testować integrację z bazą danych, należy dodać zależność do transakcyjności Arquilliana.

www.proskar.pl 15 / 47

Ważne!

Przedstawiona na poprzednim slajdzie musi być umieszczona nad zależnością BOM'a Arquilliana. Wynika to ze sposobu rozwiązywania zależności przez Maven'a. W skrócie: jeżeli jakiś artefakt zostanie zdefiniowany w BOM'ie to zależność ta zostanie zapamiętana i późniejsze wersje będą pominięte. Używanie BOM'ów niesie ze sobą to niebezpieczeństwo, że czasami do poprawnego działania potrzebujemy zależności w innych wersjach niż te, zdefiniowane w BOM'ie. Dlatego należy zdefiniować je nad BOM'em.

www.proskar.pl 16 / 47

Wymagane zależności Maven

• Skoro główny POM odpowiedzialny jest za zarządzanie wersjami zależności, można też zdefiniować tam wersje pluginów wykorzystywanych do budowania aplikacji.

• Dzięki tym definicjom każdy z modułów budowany będzie w określony przez nas sposób.

• Oprócz omówionych wcześniej zależności należy dodać pozostałe, użyte w projekcie oraz w testach (TestNG, PostgreSQL JodaTime i inne).

www.proskar.pl 17 / 47

Wymagane zależności Maven

W testowanym module należy w sekcji <dependencies> dodać zależnosci, które są używane w projekcie. Warto zwrócić uwagę na zasięg (scope), który wskazuje na sposób dostarczenia zależności przez kontener, na którym uruchomiona ostanie nasza aplikacja.

www.proskar.pl 18 / 47

Wymagane zależności Maven

• Dodajemy moduły używane w projekcie.

www.proskar.pl 19 / 47

Wymagane zależności Maven

• Kolejny element to resolver ShrinkWrapa, aby móc wygodnie budować archiwa.

• <scope>test</scope> gwarantuje, że artefakt dostępny będzie tylko w trakcie testów i nie zostanie dołączony do archiwum aplikacji po zbudowaniu.

www.proskar.pl 20 / 47

Wymagane zależności Maven

• Przyszła kolej na zależności, które dodają framework TestNG oraz rozszerzenie Arquillianowe (wymagane do wykonywania testów przy użyciu Arquilliana).

www.proskar.pl 21 / 47

Wymagane zależności Maven

• Dodajemy definicję kontenera, na którym będziemy wykonywać testy. W tym wypadku jest to zdalny serwer .

www.proskar.pl 22 / 47

Wymagane zależności Maven

• Zależność umożliwiająca dodawanie transakcyjności w testach Archqillianowych.

www.proskar.pl 23 / 47

Wymagane zależności Maven

• Na koniec należy w sekcji <build> zdefiniować plugin do wykonywania testów.

www.proskar.pl 24 / 47

Konfiguracja Arquilliana

www.proskar.pl 25 / 47

Plik konfiguracyjny

• Plik, w którym jest umieszczana konfiguracja Arquilliana nosi nazwę arquillian.xml.

• Powinien się on znajdować w zasobach testowych (Other Test Sources) w przypadku, gdy wymagane jest nadpisanie domyślnego zachowania.

• W przypadku testowania na serwerze zdalnym wymagane jest zdefiniowanie informacji o tymże serwerze.

www.proskar.pl 26 / 47

Plik konfiguracyjny

www.proskar.pl 27 / 47

Plik konfiguracyjny

• W listingu na poprzednim slajdzie zamieszczono trzy istotne informacje: – defaultProtocol - opisuje jaki protokół ma być

użyty do wdrażania.

– DeploymentExportPath – bez tej opcji ShrinkWrap będzie umieszczał testowe archiwa w systemowym folderze tymczasowym, skąd zostaną usunięte po wykonaniu testów

– Container wildfly-remote – określa parametry połączenia z serwerem zdalnym.

www.proskar.pl 28 / 47

Ważne!

Po dodaniu zależności i pliku konfiguracyjnego Arquilliana projekt powinien się budować, choć nie będą wykonywane żadne testy. Jeżeli projekt nie buduje się na tym etapie oznaczać to może nieprawidłowości w definiowaniu zależności bądź konfiguracji Arquilliana. Należy zwrócić uwagę również, czy serwer zdalny jest dostępny (uruchomiony).

www.proskar.pl 29 / 47

Testy integracyjne

www.proskar.pl 30 / 47

Tworzenie testu Arquilliana

• Aby wykonać testy w danej klasie niezbędne jest: – Rozszerzenie klasy org.jboss.arquillian.testng.Arquillian,

– Zdefiniowanie w tej klasie publicznej metody statycznej, która zwraca obiekt dziedziczący po Archive,

– Opatrzenie tej klasy adnotacją org.jboss.arquillian.container.test.api.Deployment.

www.proskar.pl 31 / 47

Deployment przy pomocy

• Zwracanie obiektu w przedstawionej wcześniej metodzie jest możliwe dzięki zastosowaniu biblioteki ShrinkWrap.

www.proskar.pl 32 / 47

Deployment przy pomocy

• Aby generować rozbudowane Archiwum testowe można przygotować klasę, którą będzie można używać w wielu testach.

www.proskar.pl 33 / 47

Przykład metody tworzącej archiwum

www.proskar.pl 34 / 47

Wymagania dotyczące bazy danych

W trakcie testów należy zapewnić połączenie do bazy testowej. Może to być źródło zarówno JTA, jak i lokalne. Należy jednak zapewnić, aby łączyło się do bazy w ten sam sposób co źródło produkcyjne. Testowa baza danych powinna być utworzona na tej samej bazie danych. W przeciwnym wypadku testy integracyjne nie będą w pełni prawidłowo testować integracji z bazą danych.

www.proskar.pl 35 / 47

Metoda resolveProjectClasses(archive)

• Metoda resolveProjectClasses(archive) odpowiedzialna jest za dodanie testowanego kodu.

www.proskar.pl 36 / 47

Metoda resolveDependencies(archive)

• Odpowiada za dodanie zależności z POM'a.

www.proskar.pl 37 / 47

Pisanie testów Arquilliana

• Testy Arquilliana polegają w głównej mierze na wykonywaniu testowanej metody oraz porównywaniu otrzymanego wyniku z wartością oczekiwaną.

www.proskar.pl 38 / 47

Pisanie testów Arquilliana

• Aby przetestować obiekt Dao należy go wstrzyknąć tak jak poniżej:

www.proskar.pl 39 / 47

Pisanie testów Arquilliana

• Kod wykonywany przed i po testach powinien być umieszczony w publicznie dostępnych metodach oznaczonych adnotacjami @BeforeTest i @AfterTest.

www.proskar.pl 40 / 47

Przykładowy test

www.proskar.pl 41 / 47

Klasa abstrakcyjna testów NG

• Implementacje Arquilliana można z powodzeniem ukryć przy pomocy klasy abstrakcyjnej, którą rozszerzałyby wszystkie testy integracyjne i funkcjonalne.

• W tym celu można stworzyć klasę abstrakcyjną, która rozszerza klasę Arquillian.

www.proskar.pl 42 / 47

Metodyka przeprowadzania testów integracyjnych z bazą danych

• Aby prawidłowo przeprowadzić testy integracyjne z bazą danych testy powinny sprawdzać jak działają wszystkie metody obiektów.

www.proskar.pl 43 / 47

Co należy sprawdzić?

• Manipulacja na danych. Czy cały CRUD działa prawidłowo? • Walidacja pól unikalnych. Czy na pewno nie można dodać

dwóch obiektów o takiej samej wartości? • Walidacja wartości generowanych po stronie bazy. Jeżeli

metoda wykonuje akcję DML na obiekcie i w trakcie tej akcji baza danych powinna modyfikować jakąś wartość obiektu, to należy sprawdzić, czy ta wartość jest dostępna.

• Test walidacji pól. Jeżeli w dano pole można wpisać tylko wartość o ściśle określonej semantyce, należy sprawdzić czy poprawna semantycznie wartość może zostać zapisana oraz czy nie istnieje jakaś wartość niepoprawna, która może zostać zapisana.

www.proskar.pl 44 / 47

Co należy sprawdzić?

• Jeżeli w projekcie istnieje DML wdrożeniowy należy sprawdzić, czy wartości znajdują się w bazie i są dostępne. Można sprawdzić ich wartości oraz liczność.

• Jeżeli baza danych posiada jakieś funkcje generujące wartości należy sprawdzić, czy zwracane wartości są poprawne semantycznie i są zgodne z założeniami projektowymi.

• Jeżeli pole jest unikalne tylko w pewnym kontekście, należy sprawdzić, czy unikalność jest tylko w tym kontekście i nie uniemożliwia nadawanie tych wartości w innych kontekstach.

• Jeżeli do pola testowego zapisywana jest jakaś enumeracja, należy walidować wprowadzanie wszystkich wartości oraz wartości spoza enumeracji oczekując błędu wstawienia.

www.proskar.pl 45 / 47

Ważne!

• Po każdym teście następuje wycofanie transakcji.

• Kolejność testów nie ma znaczenia.

www.proskar.pl 46 / 47

Dziękuję za uwagę

www.proskar.pl 47 / 47