WebDriver + SauceLab + DSL
Transcript of WebDriver + SauceLab + DSL
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.