�ݺ�ߣ

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.

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.

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.

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

• 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.

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.

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.

Implementacja testów integracyjnych
Arquilliana wykonywanych na zdalnym
serwerze WildFly

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.

• Podstawą Arquilliana jest BOM.

• 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:

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

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

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.

• 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).

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.

• Dodajemy moduły używane w projekcie.

• 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.

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

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

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

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

Konfiguracja Arquilliana

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.

Plik konfiguracyjny

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.

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).

Testy integracyjne

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.

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

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

Przykład metody tworzącej archiwum

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.

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

Metoda resolveDependencies(archive)
• Odpowiada za dodanie zależności z POM'a.

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

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

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

Przykładowy test

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.

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.

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.

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.

Ważne!
• Po każdym teście następuje wycofanie
transakcji.
• Kolejność testów nie ma znaczenia.

Dziękuję za uwagę

�ݺ�ߣ

Testy integracyjne

Recommended

More Related Content

What's hot (6)

Similar to Testy integracyjne (20)

More from PROSKAR (12)

Testy integracyjne