W prezentacji przedstawię rozwiązanie frameworka do automatyzacji testów, które zaprojektowałem, aby zapewnić wydajną i tanią w utrzymaniu automatyzację testów dla aplikacji webowej. Największym wyzwaniem było to, że aplikacja składała się z wielu modułów, z których każdy był tworzony, podobnie jak testy dla niego, przez inną firmę. Rozwiązanie oparte o repozytorium binariów pozwala na szybkie dzielenie się wytworzonym kodem testów aplikacji pomiędzy wszystkimi zespołami, co przyspiesza i obniża koszt utrzymania testów automatycznych, oraz umożliwia szybkie pisanie testów przechodzących przez wiele modułów aplikacji.

1. Architektura testów
automatycznych
dla wielomodułowej
aplikacji webowej
Piotr Grzesiak
Toruń, 16 listopada 2017

2. Agenda
 zarysowanie problemu
 specyfikacja aplikacji,
 dodatkowe warunki,
 rozwiązanie,
 szablon testów automatycznych,
 zastosowanie Artifactory,
 mocne strony rozwiązania,
 słabe strony / napotkane problemy.

3. 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,

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

5. Specyfikacja aplikacji

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

7. Rozwiązanie
 Szablon testów automatycznych:
 Java,
 WebDriver,
 Maven (!),
 Junit,
 Page Object Pattern.

8. 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…

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

10. Użycie artifactory w projekcie
Współdzielenie „silnika” testów
automatycznych
Współdzielenie klas stron Page
Object Pattern

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

12. Współdzielenie „silnika” testów
automatycznych
<dependency>
<groupId>eu.firma.core</groupId>
<artifactId>UItests</artifactId>
<version>1.2.0</version>
</dependency>

13. 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{

14. Współdzielenie „silnika” testów
automatycznych
Klasy testów dziedziczą po AbstractTest z CORE
import tests.AbstractTest;
public class LoginTest extends
AbstractTest {

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

16. Współdzielenie klas stron Page
Object Pattern
 Wysyłanie stron do artifactory za pomocą
polecenia:
mvn deploy –DskipTests

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

18. Przykład 1
Test modułu frachtów:
1. Logowanie do systemu,
2. Nawigacja do strony frachtów,
3. Reszta testu.

19. 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();

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

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

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

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

24. Q & A

25. Dziękuję
za uwagę