Page Object Model et design patterns : architecturer un framework de test

Un framework de test mal architecturé devient rapidement un fardeau : fragile, difficile à maintenir, et abandonné par l'équipe. Les design patterns vous permettent de construire des frameworks robustes qui résistent à l'épreuve du temps.

Ce guide fait partie de notre dossier sur l'automatisation des tests : définition, outils et étapes pour automatiser vos tests logiciels. Pour prendre en main l'outil, lisez aussi notre guide Playwright en français.

Qu'est-ce qu'un framework d'automatisation des tests ?

Un framework d'automatisation des tests est l'ensemble du code, des conventions et des outils qu'une équipe utilise pour écrire, exécuter et rapporter des tests automatisés de façon homogène. Il repose sur un runner de tests et une bibliothèque de pilotage, comme Playwright Test, pytest avec Selenium ou JUnit avec REST Assured, et ajoute ce que ces outils ne décident pas pour vous : l'organisation des tests, l'emplacement des sélecteurs, la création des données, la configuration des environnements et la production des rapports. Autrement dit, Playwright, Selenium ou pytest sont le moteur ; votre framework est la structure et les conventions que vous construisez autour.

Quelles sont les couches d'un framework de test ?

Un framework maintenable sépare les responsabilités en couches, pour qu'un changement à un endroit ne se propage pas dans tous les tests.

1. Tests : scénarios et assertions, écrits en langage métier.
2. Page objects ou composants : sélecteurs et interactions de chaque écran ou widget réutilisable.
3. Données de test : factories, builders et fichiers de données.
4. Fixtures : préparation et nettoyage, comme une session déjà connectée ou une base de données pré-remplie.
5. Configuration : URL, identifiants et réglages navigateur par environnement.
6. Utilitaires : clients d'API, assertions personnalisées et helpers.
7. Rapports et CI : rapports, captures, traces et le pipeline qui exécute le tout.

Page Object Model (POM) — Le fondamental

Le POM est le pattern le plus répandu en automatisation UI. Chaque page ou composant de l'application a une classe dédiée qui encapsule ses éléments et ses actions. Les tests ne manipulent jamais les sélecteurs directement — ils appellent des méthodes métier de haut niveau.

Concrètement, un test appelle loginPage.login(user, password) au lieu de répéter trois sélecteurs et un clic ; quand le formulaire de connexion change, seule la classe LoginPage est modifiée. Deux règles gardent les page objects sains. D'abord, laissez les assertions dans les tests : la documentation de Selenium recommande que les page objects ne fassent pas eux-mêmes les vérifications. Ensuite, modélisez des composants et pas seulement des pages : un en-tête, un sélecteur de date ou un tableau de données présent sur plusieurs écrans mérite sa propre classe. La documentation de Playwright décrit le même pattern pour ses tests, avec les localisateurs définis dans le constructeur de la classe de page.

Screenplay Pattern — POM évolué

Le Screenplay Pattern (utilisé dans Serenity BDD) modélise les tests comme des scénarios d'acteurs qui accomplissent des tâches via des capacités. Plus verbose que le POM, mais plus expressif pour les tests comportementaux complexes et les équipes BDD.

Concrètement, le Screenplay organise les tests autour d'acteurs qui ont des capacités (naviguer sur le web, appeler une API), accomplissent des tâches (passer une commande) et posent des questions (quel est le total du panier ?). Il est implémenté notamment par Serenity BDD en Java et Serenity/JS en JavaScript et TypeScript. Il demande plus de code que le POM, mais se compose mieux dans les grandes suites, car les tâches sont construites à partir d'interactions plus petites au lieu de faire grossir des classes de page. Pour des suites petites ou moyennes, le POM suffit généralement.

Factory Pattern pour les données de test

Ne créez pas vos objets de test à la main dans chaque test. Utilisez des factories (ou builders) qui génèrent des objets configurables avec des valeurs par défaut sensées. Combinez avec Faker pour des données réalistes.

Strategy Pattern pour les environnements

Pour gérer plusieurs environnements (dev, staging, prod), le Strategy Pattern permet d'injecter la configuration au runtime. Vos tests restent identiques, seule la stratégie de configuration change.

Quels autres design patterns sont utiles dans un framework de test ?

Au-delà des page objects, quelques patterns classiques résolvent des problèmes récurrents.

Côté données, notre guide du data-driven testing montre comment alimenter un même test avec de nombreux jeux de données.

Structure de projet recommandée

Reproduisez les couches dans les dossiers, pour que chacun sache où placer une modification :

Faut-il bâtir son framework sur Playwright, Cypress ou Selenium ?

Bâtissez-le sur l'outil qui correspond au langage de votre équipe et aux besoins de votre application ; les patterns ci-dessus fonctionnent avec les trois. Playwright prend en charge TypeScript/JavaScript, Python, Java et .NET, et intègre son propre runner de tests pour JavaScript et TypeScript. Cypress se limite à JavaScript/TypeScript et exécute les tests dans le navigateur. Selenium implémente le standard W3C WebDriver, prend en charge de nombreux langages et s'appuie sur un runner séparé comme JUnit, TestNG ou pytest. Notre comparatif détaillé Playwright vs Cypress aide à faire ce choix.

Anti-patterns à éviter

La plupart des frameworks échouent par accumulation de raccourcis plutôt qu'à cause d'un mauvais choix d'outil.

1. Sélecteurs dans les tests : ne jamais mettre de sélecteurs en dur dans les tests, le même sélecteur finit copié dans de nombreux fichiers.
2. Tests dépendants de l'ordre : le test B ne passe que si le test A s'est exécuté avant.
3. Logique de navigation dupliquée : ne la recopiez pas d'un test à l'autre, créez des helpers.
4. Attentes fixes : des appels sleep() au lieu d'attendre une condition avec des attentes explicites.
5. « God page objects » : une seule classe énorme pour toute l'application.
6. Assertions cachées dans les helpers : des échecs difficiles à relier au scénario.
7. Sur-ingénierie : des couches d'abstraction que personne dans l'équipe ne comprend.

Ces règles sont détaillées dans nos 10 bonnes pratiques de l'automatisation des tests. Pour savoir si l'automatisation sera rentable dans votre équipe, faites le calcul avec notre calculateur de ROI de l'automatisation des tests.

Questions fréquentes