Vlákno názorů k článku Testování webových aplikací – návrhový vzor PageObject od anonym - Existuje v Javě* něco jako JSDOM? Testování UI...

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