Co je Page Object Model a kdy pomáhá
Page Object Model (POM) je návrhový vzor pro automatizované testy uživatelského rozhraní. Technické detaily obrazovky, například způsob nalezení polí a tlačítek, jsou uložené v samostatném objektu. Samotný test potom popisuje záměr uživatele, například „přihlas uživatele“, namísto série nízkoúrovňových kliknutí.
Jaký problém řeší
Bez společné vrstvy může mít každý test vlastní kopii kroků pro přihlášení. Když vývojáři změní označení pole nebo rozdělí formulář na dvě obrazovky, je nutné hledat stejnou úpravu na mnoha místech. Kód se začne rozcházet a část testů používá starý postup.
Taková duplicita zvyšuje náklady na každou změnu a ztěžuje zaškolení nového člena týmu. Je také jedním z důvodů, proč testovací sady postupně ztrácejí důvěru týmu.
Jak Page Object Model funguje
Představte si přihlašovací obrazovku. Její objekt zná pole pro e-mail, pole pro heslo a tlačítko pro odeslání. Navenek nabídne metodu, například signIn(email, password). Test tuto metodu použije a následně ověří výsledek, například zobrazení účtu uživatele.
Pokud se změní způsob nalezení tlačítka, oprava zůstane v objektu přihlašovací obrazovky. Pokud se změní samotný proces nebo očekávaný výsledek, je nutné upravit také příslušné testy. POM tedy omezuje duplicitu, ale nezaručuje, že redesign nebude vyžadovat další změny.
U složitějších aplikací nemusí jeden objekt představovat celou stránku. Opakované části, jako jsou navigace, tabulka nebo košík, mohou mít vlastní komponentové objekty. Díky tomu nevznikne jeden velký soubor, který zná vše.
POM doplňujeme stabilními a významovými selektory a izolovanými daty. Samotný návrhový vzor nevyřeší nevhodné čekání, sdílené účty ani nestabilní prostředí.
Na co si dát pozor
Page Object nemá skrývat celý záměr testu. Pokud obsahuje ověření všech možných výsledků nebo desítky nesouvisejících pracovních postupů, testy se sice zkrátí, ale budou hůře čitelné. Objekty mají pojmenovat služby obrazovky; rozhodnutí o tom, co se ověřuje, má zůstat viditelné v testu.
POM také není povinný pro každý malý projekt. U několika jednoduchých testů může stačit menší vrstva opakovaně použitelných funkcí. Architektura má odpovídat velikosti sady a očekávaným změnám.
Co tím získáte
- Méně duplicitního kódu a jedno místo pro často používané prvky.
- Čitelnější scénáře, kterým rozumí i člověk bez znalosti selektorů.
- Jednodušší úpravy při běžných změnách rozhraní.
- Jasnější rozdělení odpovědností v rostoucí testovací sadě.
Další krok
Vyberte jeden opakovaný proces, například přihlášení, a zkontrolujte, na kolika místech jsou jeho kroky zkopírované. Pokud chcete navrhnout udržitelnou strukturu nové sady nebo uklidit stávající, ozvěte se nám. Rozsah architektury přizpůsobíme vašim scénářům a týmu.