Page Object Model (POM) is een architecturaal patroon voor het organiseren van de code van geautomatiseerde tests, vooral in UI-testing. Het biedt de mogelijkheid om afzonderlijke klassen of objecten te maken voor de logische representatie van elke pagina van de applicatie, waarbij methoden worden gedefinieerd voor interactie met de elementen en acties daarop.
Achtergrond van de vraag: Vroeger werden geautomatiseerde tests "zoals het is" geschreven, waarbij rechtstreeks met de locators van elementen in de tests werd gewerkt, wat leidde tot duplicatie van code en moeilijke onderhoudbaarheid. Met de introductie van POM werd het mogelijk om alles wat met een bepaalde pagina te maken had naar een aparte klasse te verplaatsen, waardoor geautomatiseerde tests gemakkelijker te onderhouden zijn.
Probleem: Zonder het structureren van tests in grote projecten hoopt "rommelige" code zich snel op. Elke wijziging in de interface vereist het bijwerken van talloze tests, wat leidt tot hoge onderhoudskosten.
Oplossing: POM maakt het mogelijk om acties en elementen centraal te beheren, vermindert duplicatie en vereenvoudigt de opschaling van de testinfrastructuur. Als u bijvoorbeeld de locator van een knop moet wijzigen, wordt de wijziging slechts op één plek doorgevoerd — in de Page Object, en niet in alle tests.
Belangrijke kenmerken:
Is het mogelijk om geautomatiseerde tests uit te voeren zonder het POM-patroon?
Ja, maar deze benadering zal leiden tot duplicatie van code, hoge onderhoudskosten en een gebrek aan schaalbaarheid.
Moet elk element van de pagina in een aparte Page Object worden geplaatst?
Nee, een Page Object wordt gemaakt voor logische pagina's die gerelateerde elementen en acties bevatten; soms kunnen aparte helper-entiteiten worden gebruikt voor kleinere herhalende blokken (bijvoorbeeld componenten).
Lost POM alle architecturale problemen van geautomatiseerde tests op?
Nee, het helpt de logica van de interactie met interfaces te structureren, maar definieert niet de volledige architectuur van het testframework — bijvoorbeeld de verwerking van gegevens, generatie van rapporten en beheer van de status van de applicatie.
Geautomatiseerde tests werden geschreven zonder POM — alle acties werden rechtstreeks in de testmethoden beschreven. Als gevolg daarvan vereiste een eenvoudige wijziging van de id van een knop op een pagina de aanpassing van 35 tests, waarvan vele ongeldig werden, terwijl andere gewoon niet meer uitvoerbaar waren.
Voordelen:
Nadelen:
In een nieuw project zijn de tests volgens POM opgebouwd: klassen voor pagina's zijn toegevoegd, interacties met elementen zijn ingekapseld, er is gebruikgemaakt van overerving voor gemeenschappelijke patronen.
Voordelen:
Nadelen: