Le Page Object Model (POM) est un modèle architectural pour organiser le code des tests automatisés, en particulier dans les tests UI. Il propose de créer des classes ou des objets distincts pour représenter logiquement chaque page de l'application, définissant des méthodes pour interagir avec les éléments et les actions sur ceux-ci.
Historique de la question : Auparavant, les tests automatisés étaient écrits "tels quels" — en interagissant directement avec les localisateurs d'éléments dans les tests eux-mêmes, ce qui entraînait une duplication du code et une maintenance compliquée. Avec l'introduction du POM, il est devenu possible de regrouper tout ce qui concerne une page particulière dans une classe distincte, rendant les tests automatisés plus faciles à maintenir.
Problème : Sans structuration des tests dans de grands projets, un code "désordonné" s'accumule rapidement. Tout changement dans l'interface nécessite la mise à jour de nombreux tests, ce qui entraîne un coût de maintenance élevé.
Solution : Le POM permet de gérer de manière centralisée les actions et les éléments, réduit la duplication, et simplifie l'évolutivité de l'infrastructure de test. Par exemple, si vous devez modifier le localisateur d'un bouton, la correction se fait à un seul endroit — dans le Page Object, et non dans tous les tests.
Caractéristiques clés :
Peut-on réaliser des tests automatisés sans le modèle POM ?
Oui, mais cette approche entraînera une duplication de code, un coût de maintenance élevé et l'impossibilité d'évoluer.
Est-il obligatoire de créer un Page Object pour chaque élément de la page ?
Non, un Page Object est créé pour des pages logiques, incluant des éléments et des actions associés, parfois pour de petits blocs répétitifs, on peut utiliser des entités auxiliaires distinctes (par exemple, des composants).
Le POM résout-il toutes les questions architecturales des tests automatisés ?
Non, il aide à structurer la logique des interactions avec les interfaces, mais ne définit pas l'architecture complète du framework de test — par exemple, le traitement des données, la génération de rapports et la gestion de l'état de l'application.
Les tests automatisés étaient écrits sans POM — toutes les actions étaient écrites directement dans les méthodes de test. En conséquence, un simple changement de l'id d'un bouton sur une page a nécessité de modifier 35 tests, dont beaucoup sont devenus incorrects, d'autres ont simplement cessé de fonctionner.
Avantages :
Inconvénients :
Dans un nouveau projet, les tests ont été construits selon le POM : des classes de pages ont été ajoutées, le travail avec les éléments a été encapsulé, et l'héritage a été utilisé pour des modèles communs.
Avantages :
Inconvénients :