Architektura testów

automatycznych

dla wielomodułowej

aplikacji webowej

Piotr Grzesiak

Toruń, 16 listopada 2017

Agenda

zarysowanie problemu

specyfikacja aplikacji,

dodatkowe warunki,

rozwiązanie,

szablon testów automatycznych,

zastosowanie Artifactory,

mocne strony rozwiązania,

słabe strony / napotkane problemy.

Specyfikacja aplikacji

Wiele modułów:

moduły pisane przez różne firmy,

możliwość przekazywania modułów pomiędzy

firmami,

każdy moduł musi mieć testy automatyczne,

Specyfikacja aplikacji

Wiele modułów:

na różnych środowiskach moduły mogą być w

różnych wersjach,

jeden moduł który odpowiada za osadzanie

pozostałych modułów,

konieczność pisania testów automatycznych

e2e.

Specyfikacja aplikacji

Warunki dodatkowe

różny poziom automatyzacji w zespołach,

skomplikowane procesy biznesowe w

niektórych modułach,

docelowe wpięcie w proces CI,

konieczność monitorowania wykonania testów.

Rozwiązanie

Szablon testów automatycznych:

Java,

WebDriver,

Maven (!),

Junit,

Page Object Pattern.

Rozwiązanie

Szablon testów automatycznych:

opakowanie akcji Webdrivera,

parametryzacja wywołania testów,

używanie suit testowych,

użycie obiektów danych,

komentarze w formacie javadoc dla

biznesowych metod w klasach stron,

Page Object Pattern do kwadratu…

Użycie artifactory w projekcie

Artifactory – Repozytorium artefaktów.

Dwie podstawowe funkcje:

1. Jest źródłem artefaktów, np. bibliotek

potrzebnych do budowania projektu,

2. miejscem przechowywania artefaktów

powstałych w procesie budowania aplikacji.

Użycie artifactory w projekcie

Współdzielenie „silnika” testów automatycznych

Współdzielenie klas stron PageObject Pattern

Współdzielenie „silnika” testów

automatycznych

Biblioteka CORE:

- zależności do WebDriver’a, Junit’a,

WebDriverManger’a,

- AbstractPage, AbstractTest,

- Raportowanie do Zephyra (plugin Jiry),

- Klasy konfiguracyjne,

- pozostałe niezbędne zależności.

Współdzielenie „silnika” testów

automatycznych

<dependency>

<groupId>eu.firma.core</groupId>

<artifactId>UItests</artifactId>

<version>1.2.0</version>

</dependency>

Współdzielenie „silnika” testów

automatycznych

Klasy stron w projekcie dziedziczą po

AbstratcPage z biblioteki CORE:

import

eu.firma.core.webpages.AbstractPage;

public class LoginPage extends

AbstractPage{

Współdzielenie „silnika” testów

automatycznych

Klasy testów dziedziczą po AbstractTest z CORE

import tests.AbstractTest;

public class LoginTest extends

AbstractTest {

Współdzielenie klas stron Page

Object Pattern

Unikalna nazwa projektu i wszystkich pakietów

<groupId>eu.trans.webmessenger</groupId> Wspólna nazwa modułu

<artifactId>webdriver-UI-tests</artifactId> Wersja projektu testów odpowiadająca wersji modułu

aplikacji.

<version>0.0.1</version>

Przechowywanie stron w projekcie w folderze źródłowym: src/main/java

Współdzielenie klas stron Page

Object Pattern

Wysyłanie stron do artifactory za pomocą

polecenia:

mvn deploy –DskipTests

Współdzielenie klas stron Page

Object Pattern

Importowanie stron z artifactory:

<dependency>

<groupId>eu.firma.login</groupId>

<artifactId>UItests</artifactId>

<version>3.4.5</version>

</dependency>

Przykład 1

Test modułu frachtów:

1. Logowanie do systemu,

2. Nawigacja do strony frachtów,

3. Reszta testu.

Przykład 1

Test modułu frachtów:

import eu.firma.login.webpages.LoginPage;

import eu.firma.frame.webpages.FramePage;

1. Logowanie do systemu

FramePage framePage = loginPage.login(user, password);

2. Nawigowanie do modułu frachtów

FreightsModule fm = framePage.navigateToFreightsModule();

Przykład 2

Smoke testy używane do monitorowania środowiska.

Brak własnego AbstractPage

AbstractTestLocal dziedziczy po AbstractTest

Wywołuje tylko metody ze stron modułów.

Przykład 3

Automatyczne testy e2e (To-Do)

Wykorzystanie wyłącznie metod z innych

modułów do zautomatyzowania testów e2e

przez cały system.

Mocne strony

ograniczenie duplikowania kodu,

centralne zarządzanie całym framework’iem,

utrzymywanie jedynie własnych metod,

szybkie propagowanie zmian w projekcie,

możliwość wersjonowania testów poprzez

POM

słabe strony / napotkane

problemy

konieczne zaangażowanie wszystkich zespołów,

niezbędna doskonała komunikacja,

niezbędne szybkie reakcje zespołów,

Kłopoty z zależnościami -

JAR Hell

Q & A

Dziękuję

za uwagę