Názory k článku Testování webových aplikací – návrhový vzor PageObject

Vyzkousejte nekdy Cypress.js, kod bude.prehlednejsi a citelnejsi :)

Děkuji za zajímavý námět, který se budu snažit v budoucnu vyzkoušet.
BTW
Toto je další vedlejší účinek článku: získat od odborné veřejnosti náměty na jiné postupy či metody - díky.

Celý projekt byl napsán v Javě, takže Java byla i první volbou pro psaní testů. Principiálně (po napsání druhé verze testů) nemám problém s přehledností a čitelností kódu, jsem s tím spokojen. Navíc bude možné v Javě vytvořenou "knihovnu" dále používat pro jiné typy testů v jiných prostředích (aktuálně zkoušíme Robot Framework). To, s čím máme lehké potíže, je větší časová náročnost testů - viz moji odpověď na další příspěvek.
V každém případě mi ale spojení PageObject v Seleniu a JUnit5 dalo značné možnosti, takže teď jsem přesvědčen, že je to cesta, která pro menší až střední projekty vede relativně přímočaře k úspěšnému cíli. Tím ale samozřejmě nevylučuji, že použití jiných nástrojů by k tomuto cíli také vedlo.
P.Herout

Existuje v Javě* něco jako JSDOM? Testování UI pouze Seleniem je dost pomalé, neumožňuje časté spouštění testů.

* asi lépe psát větší část UI testů přímo v JS.

2. 10. 2019, 09:52 editováno autorem komentáře

Kde se netestuje přímo fyzický vzhled, ale jen existence elementu a podobně, je renderování stránky v plnohodnotném browseru zbytečný overhead. Rychlost testů je často podceňovaná metrika, ale dost ovlivňuje komfort vývoje.

Možná hloupé přirovnání, ale v letectví je také snaha provádět pokud možno co nejvíc testů na zemi, ve vzduchu jen konečné ověření.

Zcela správně jste "vyhmátl" asi největší slabinu použitého postupu - malou rychlost. Ta je zejména u obsahů modálních oken zjevně patrná.
Pokud by byl známý a vyzkoušený nějaký prostředek na urychlení, pak by určitě stálo za to, jej zkusit. BTW Použití Chrome v headless modu to rozhodně není.
Na druhou stranu - nechtěl bych jen kvůli rychlosti průběhů testů změnit celý koncept, který je dle mého funkční a spolehlivý.
Všech asi 1000 testů běží zhruba 40 minut, což je ještě akceptovatelné.
A při vývoji, kdy není nutné testovat pokaždé všechno, je největším zdržením aktivace (náběh) příslušného web driveru. Samotné jednotlivé testy na téže webové stránce jsou otázkou vteřin.
P.Herout

Neřekl bych, ze 40 minut na 1000 UI testů je až tak pomalé. Pochybuji, že běžný vývojář si bude pouštět lokálně celou sadu po každé změně. Ten čas bych porovnával s tím, jak dlouho by trvalo QA oddělení "proklikat" těch 1000 testů ručně...a to je mnohem víc než 40 minut... bohužel se tak v praxi často děje, hlavně u větších firem, které si mohou dovolit živit větší QA oddělení :).

OK, chápu, že se jedná o integrační testy. I kdyby vývojář pokaždé testoval malou podmnožinu těch testů, tak se musí spouštět (headless) browser, jsou tam nejspíš nějaké timeouty, kryptické chybové hlášky, případné chyby musí stejně odhalovat vizuální kontrolou atd. Běžné transformace DOMu se dají testovat pomocí knihoven, které simulují DOM, ale nic nerenderují, běží ve vlákně aplikace, tak nemusíte řešit čekání atd. Nemusí trvat víc než pár sekund.

AFAIK i headless browser renderuje do nějakého neviditelného bufferu. JSDOM je něco jiného, jen jednoduchá knihovna, která simuluje operace nad DOM stromem.

Omlouvám se za to, že jsem napsal svoji reakci částečně krypticky ;-)
Rozhodně jsem nechtěl míchat dohromady přístupy, kdy se využívá (jakékoliv) analýzy DOM s použitím headless browseru. Zřejmě to tak vyznělo a to je mi líto.
Ta má poznámka o headless Chromu měla ten význam, že pro daný (již existující) koncept testů bylo téměř bezproblémové (stačilo najít jak se headless Chrome inicializuje) jej vyzkoušet. A výsledkem bylo totální zklamání, protože se doba testů zkrátila cca o jedno procento.
Přístup pomocí analýzy DOM by ale s nenulovou pravděpodobností vyžadoval jiný přístup k celému konceptu testů. A to jsem nechtěl podstupovat.
Čili jednoznačně - naprosto nezpochybňuji možnost využití (JS)DOM a věřím, že by ke zrychlení (pravděpodobně podstatnému) došlo. Ale touto cestou jsem zatím nebyl nucen jít.
P.Herout

Dneska bych si svůj page object nepsal a použil nějaké předpřipravené řešení jako Geb

Nemohu hodnoti to, co jsem nevyzkoušel, takže další text berte, prosím, s rezervou.
Letmým pohledem na stránky Geb mám pocit, že se jedná o nástroj, který bude spolehlivý pro jednodušší stránky (opravdu je to jen a jen pocit!). Ovšem v naší testované aplikaci jsme záměrně připravili i složitější typ stránky s komplikovanějšími tabulkami (tři úrovně složitosti). Nevím, zda by si s tím Geb poradil. Selenium (a Java) si s tím poradí.
P.Herout

Pro upřesnění. Geb není něco zcela odlišného, naopak na Seleniu staví. Nikomu to nenutím, ani neříkám, že to bude bezproblémové. Geb preferuji i z toho důvodu, že mám slabost pro Groovy.

Díky za články, jsou pěkně napsané. Prosím pokračujte. Spolu s články P. Tišnovského je to jeden z důvodů sem chodit a vracet se.

Zdravím Vás pane Heroute.
Čirou náhodou se můj profesní život motá kolem testování už od roku 2007. Trošku si dovolím nějaké útržkovité podměty a zkušenosti.

PageObject návrhový vzor fungoval dobře před pár lety. S rozvojem single page aplikací začínají tyto objekty pomalu narůstat do velikostí, kdy už prakticky nejsou přehledné.

Jeden framework, co se snaží poněkud zjednodušit práci s elementy je https://selenide.org/ a jeden pattern, který se mi osvědčil je zde: https://www.automatetheplanet.com/advanced-page-object-pattern/ akorát pro C#, nic méně, na pochopení myšlenky to stačí.

Vždy říkám lidem, co píšou testy, ať přemýšlí tak, že pokud píší PageObject, píší defakto api k té stránce, ať píší ty metody tak, že odpovídají akcím prováděným na této stránce. Zkrátka, aby se daly tyto metody znovu dobře použít. Single Responsibility princip je základem.

Zpravidla si napíšu vždy nějakého abstraktního předka pro PageObject, který za mě řeší získání objektu, automatické skrolování k místě, kde je zobrazený atd. S rozvojem klientsky renderovaných aplikací, Ajaxu a podobně, je čím dál častěji potřeba na dotyčné elementy čekat, synchronizovat se atd. To vše jde do této abstraktní třídy.

Skutečná sranda začíná i tehdy, kdy jsme měli ve firmě Shop, který byl lokalizován do 10 jazyků a ještě do několika brendů. Napsat Testy tak, aby dokázaly běžet na všech shopech, člověk dokázal definovat, který test je pro který shop relevantní, případně napsat test, který například pro Švédsko provede finální test trošku jinak, byla docela výzva. Nakonec kombinace následujích frameworků vyřešila vše:

Cucumber - testy napsané tak, aby jim rozumněli všichni. (Slovy) https://cucumber.io/
Spring - Dependency Injection, Profile a konfigurační framework pro jednotlivé shopy
Selenide - Výrazné zjednodušení práce s elementy.
Selenium
Selenium Server

Díky této kombinaci jsme měli dvakrát denně otestované všechny obchody a to v různých rozlišeních a různých prohlížečích. Byl to boj, hlavně udržet ty testy stabilní, (protože testovací prostředí zrovna moc stabilní není). I tak trvalo relativně dlouho, než programátoři začali výsledkům těchto testů věřit. Ale výsledek za to stál.

Hodně štěstí a chuti dál.
S pozdravem
Zdeněk Jonáš (Dione)

Zdravím svého bývalého studenta, který evidentně předčil svého učitele. ;-)
Nemá cenu, abych Váš příspěvek jakkoliv komentoval, zkušeností máte o deset let víc než já.
Díky za všechny tipy na vyjmenované frameworky. O některých vím (Cucumber), některé jsou novinkou (Selenide), kterou určitě prozkoumám.
P.Herout