Le design pattern Page Object Model

Vers une meilleure modélisation de nos tests

Ne vous êtes-vous pas sentis frustrés ou lésés pendant l’exécution de nos tests jusqu’à présent ? En effet, certains de nos tests demandent le même enchaînement d’actions au niveau du comportement à tester. Nous avons donc du code qui se répète dans nos fonctions de tests, ce qui va à l’encontre des bonnes pratiques de la programmation, quel que soit le langage ou l’objectif de l’application que nous développons.

Corrigeons ce désagrément en augmentant la lisibilité et la maintenabilité de notre code avec la programmation orientée objet et les design patterns dont Page Object Model.

Le design pattern Page Object Model (POM)

Lorsque nous testons le comportement d’une page HTML, nous testons ses propriétés et celles de ses balises ainsi que les actions que nous pouvons faire avec ces dernières. Nous pouvons donc la modéliser comme une classe : les attributs sont ses propriétés et ses balises, et les méthodes les interactions possibles. C’est le principe du design pattern Page Object Model ou POM.

Une classe peut représenter toute la page HTML ou seulement une partie. Si nous n’avons besoin que de certains éléments Web à tester, il n’est en rien pertinent de tous les inclure dans notre classe.

Nous déportons donc le code spécifique du comportement de la classe avec le design pattern Page Object Model. Ainsi, si la page HTML change, nous n’avons qu’à changer la classe, et non pas les tests, sauf si un nouveau comportement est ajouté. À ce moment-là, nous devons juste ajouter aux tests ce nouveau comportement.

L’organisation de notre code est donc beaucoup plus propre.

Mettons en place le design pattern Page Object Model avec les tests des applications Web du chapitre Les waits pour une interaction optimale.

1. Application multipage

Une page HTML égale une classe, il nous faut donc déclarer deux classes pour cette application : HomePage pour la page d’accueil et ConnectedPage pour la seconde page.

Dans la classe HomePage, nous allons avoir besoin des éléments Web liés à la traduction des labels du formulaire, c’est-à-dire du bouton lançant la traduction, des entrées du formulaire ainsi que de la zone d’affichage des messages d’erreur de saisie. Nous devons également pouvoir lancer les comportements pour traduire et valider le formulaire.

from selenium import webdriver  
from selenium.webdriver.common.by import By  
from selenium.webdriver.support import expected_conditions as EC  
from selenium.webdriver.common.action_chains import ActionChains  
from selenium.webdriver.support.wait import webDriverWait  
   
class HomePage():  
     
    def __init__(self, webDriver) :  
          self.browser = webDriver  
         ...

Exercices

Reprenez les deux tests des exercices du chapitre Les waits pour une interaction optimale et modifiez-les en appliquant le design pattern Page Object Model.