WebDriver + SauceLab + DSL

...czyli jak ugryźliśmy testy warstwy UI w firmie CodeWise

Michał Dec

Michał Dec

QA przez ostatnie...4 lata (Comarch, Lumesse),

aktualnie pracuję w firmie CodeWise – ciągle szukamy nowych

osób;),

pasjonat WebDrivera.

Agenda

1. Czym jest Voluum? (słów parę o aplikacji),

2. Nim zaczniemy pisać – założenia, których się trzymamy,

3. Przejrzysty DSL i testy „end-to-end” warstwy webowej,

4. Lessons learned – czyli jakie pojawiły się pytania,

5. Izolacja testów warstwy webowej.

Czym jest Voluum?

dedykowany system raportowy dla marketerów afiliacyjnych,

cloud hosted,

własne rozwiązanie bazodanowe,

sercem jest back-end ale...duże znaczenie GUI usability,

system w pełni modularny (kilka modułów komunikujących się

za pośrednictwem REST WS).

Czym jest Voluum?

CORE

PANEL (GUI)

)

SECURITY

)

REPORTS

)

DB

{JSON}

{JSON}

{JSON}

Czym jest Voluum?

Nim zaczniemy pisać – założenia, których się trzymamy

testy automatyczne GUI muszą być stabilne, a koszt ich

utrzymania jak najniższy,

tworzymy aplikację tak by była „testowalna”,

nie utrzymujemy własnej infrastruktury do uruchamiania

testów (SeleniumGrid on EC2 vs SauceLab),

czas wykonania testów jest krótki (wielowątkowość testów +

całkowita integralność każdego testu),

korzystamy z WebDrivera + JAVA.

Przejrzysty DSL i testy „end-to-end” GUI

„całkowita integralność testów” – konieczna prekonfiguracja dla

każdego testu na poziomie backendu -> wykorzystujemy API

systemu Builder Pattern

HTTPClient

Przejrzysty DSL i testy „end-to-end” GUI

kontrolowanie zachowania WebDrivera (wrapping WebDriver,

EventFiringWebDriver)

Przejrzysty DSL i testy „end-to-end” GUI

sprawdzanie JS errors (dodatkowe zabezpieczenie)

czytelne page asserty

struktura, która przechowuje

wszystkie JS errors

Przejrzysty DSL i testy „end-to-end” GUI

SauceLab dostarcza infrastruktury do uruchamiania testów

historia daily buildów,

niskie latency (aplikacja deployowana na serwerach AWS),

kilkadziesiąt konfiguracji OS/browser),

stosunkowo niski koszt (4000 minut/150$ - 10 równoległych

sesji) w porównaniu do kosztów tworzenia/utrzymania własnej

infrastruktury.

Lessons learned – czyli jakie pojawiły się pytania

1. Co tak naprawdę testują testy GUI „end-to-end”?,

2. Brak konkretnej informacji, w którym miejscu systemu wystąpił

problem (DB, backend, GUI?),

3. Brak możliwości pokrycia wszystkich (czasami bardzo

kluczowych) scenariuszy – np. paginacja,

4. Duży nakład pracy związany z prekonfiguracją środowiska i jego

utrzymaniem.

Izolacja testów warstwy webowej

kod źródłowy warstwy UI, jest deployowany przez testy (WAR + Cargo

Tomcat Plugin),

konieczność zamockowania warstwy, którą konsumuje UI

(Jetty/WireMock),

możliwość pokrycia dodatkowych scenariuszy (mockowanie negatywnych

ścieżek),

zupełnie inne podejście do assertowania zachowania GUI (nasłuchiwanie

czy GUI wygenerował poprawny request HTTP),

problemy przy implementacji architektury, która pozwala odpalać testy

równolegle.

Izolacja testów warstwy webowej

Mockowanie back-endu (Jetty)

ładowanie odpowiedzi z pliku

JSON

nasłuchiwanie requestów HTTP generowanych przez GUI

Izolacja testów warstwy webowej

Mockowanie back-endu (WireMock - wiremock.org)

rejestracja odpowiedzi WireMocka

weryfikacja zachowania UI

weryfikacja requestów

HTTP

Izolacja testów warstwy webowej

Cargo Tomcat Plugin (org.codehaus.cargo.container)

1) zainstaluje na lokalnej maszynie Tomcata (jeżeli jest to konieczne),

2) pobierz najnowaszą wersję artefaktu z Nexusa/Artificatory (standardowe

API),

3) wystartuj serwer Tomcata z odpowiednią konfiguracją,

4) uruchom na serwerze ściągnięty artefakt,

5) po zakończonych testach – Tomcat stop.