Pandora : pourquoi nous avons construit notre propre framework

Construire son propre framework d’automatisation est, presque toujours, une mauvaise idée.

C’est un projet logiciel de plus à maintenir, une documentation à écrire, une courbe d’apprentissage à faire subir à chaque nouvel arrivant. Le conseil par défaut — assembler des briques éprouvées et ne rien écrire de plus — est le bon dans la grande majorité des cas.

Nous avons quand même construit Pandora. Cet article explique dans quelles conditions cette décision se justifie, et ce qu’elle implique.

Note de transparence. Cet article traite de la démarche de conception d’un framework d’automatisation et des partis pris de Pandora. Le dépôt et sa documentation technique seront publiés séparément ; nous n’illustrons ici aucune API avant qu’elle ne soit publiquement consultable. Ce qui est décrit ci-dessous relève des principes d’architecture, pas de la référence d’usage.

Ce qu’est Pandora

Pandora est le framework d’automatisation de tests développé par STRATEST. Sa version 1.0.0 s’appuie sur un socle Java volontairement classique : Selenium pour le pilotage des navigateurs, TestNG et JUnit pour l’exécution, Allure pour le rapport, Maven pour la construction. La fiche technique de Pandora reprend cette pile, la version, et l’état de publication du dépôt.

Aucun de ces choix n’est original, et c’est délibéré. Un framework qui repose sur des briques que tout le monde connaît reste lisible par quelqu’un qui ne l’a jamais vu. Un framework qui invente sa propre notion d’exécution, son propre format de rapport et son propre gestionnaire de dépendances enferme ses utilisateurs.

Pandora sert deux usages : nos missions d’industrialisation, et le support technique de nos formations à l’automatisation.

Les trois questions à se poser avant d’écrire la première ligne

1. Est-ce que le problème est le vôtre, ou celui de tout le monde ?

Si votre difficulté est de lancer un navigateur, d’attendre un élément ou de produire un rapport, ne construisez rien : ces problèmes sont résolus, et mieux que vous ne les résoudrez.

Un framework maison ne se justifie que lorsque le problème est spécifique — une contrainte de votre domaine, de votre architecture applicative, ou de votre organisation, que les outils génériques ne connaissent pas.

2. Qui le maintiendra dans trois ans ?

C’est la question qui tue la plupart des frameworks maison.

Ils sont écrits par une personne, souvent la plus compétente de l’équipe. Cette personne part. Le framework reste, mal documenté, avec des choix que plus personne ne peut expliquer. L’équipe le contourne, puis le remplace.

Un framework maison n’est viable que s’il est traité comme un produit : versionné, documenté, avec des notes de version et des personnes identifiées pour le maintenir.

3. Est-ce que vous construisez un outil, ou un modèle ?

C’est la distinction la plus utile, et celle que nous avons retenue.

Un outil fait quelque chose à votre place. Il gagne du temps, et il cache le fonctionnement.

Un modèle montre comment faire. Il structure, il impose une manière de s’organiser, et il reste lisible — parce que son objet est précisément d’être lu.

Le parti pris de Pandora : un modèle, pas une boîte noire

Nous avons construit Pandora comme un modèle, pour une raison qui tient à la fois à nos missions et à nos formations.

En mission d’industrialisation, nous ne voulons pas laisser derrière nous une suite de tests que seule STRATEST sait maintenir. Un cabinet qui automatise à la place de son client crée une dépendance, et cette dépendance finit toujours par se payer. Ce qui doit rester après notre départ, c’est une équipe capable de faire évoluer sa suite sans nous.

En formation, la contrainte est encore plus forte : un apprenant doit pouvoir ouvrir le framework et comprendre pourquoi il est organisé ainsi. Un framework opaque n’apprend rien. Il apprend à utiliser un framework opaque.

Conséquences concrètes de ce parti pris :

• la structure est explicite plutôt que magique. Nous préférons quelques lignes lisibles à une couche d’abstraction qui devine. La configuration par convention est confortable jusqu’au jour où l’on veut sortir de la convention ;
• les briques restent apparentes. Un utilisateur de Pandora écrit du Selenium et du TestNG, pas un langage intermédiaire. Ce qu’il apprend lui reste utile ailleurs, y compris s’il quitte Pandora ;
• le rapport est un citoyen de première classe. Un test qui échoue doit être compréhensible depuis le rapport, sans rejouer localement. C’est le rôle d’Allure, et c’est une exigence structurante, pas un ajout.

Ce qu’un framework doit imposer, et ce qu’il doit laisser libre

Un bon framework contraint peu de choses, mais les contraint réellement.

Ce qu’il doit imposer :

• la séparation entre l’intention du test et la connaissance de l’interface — un sélecteur n’a rien à faire dans un test ;
• l’isolation des données entre tests, sans quoi aucune exécution parallèle n’est fiable ;
• l’expression des attentes en conditions plutôt qu’en durées ;
• une structure de rapport permettant de comprendre un échec sans le reproduire.

Ce qu’il doit laisser libre :

• l’organisation des suites, qui dépend de l’équipe ;
• le découpage des objets de page, qui dépend du produit ;
• le choix d’ajouter des niveaux de test, qui dépend de l’architecture.

Un framework qui impose tout devient un carcan que les équipes contournent. Un framework qui n’impose rien n’est qu’une collection de dépendances.

Ce que l’usage en formation a changé

Pandora sert de support à nos sessions d’automatisation. Les participants y découvrent Selenium, TestNG, JUnit, Allure et Maven, puis passent en mise en situation : quatre applications à automatiser à partir de user stories, chacun intégrant une équipe QA simulée où il est propriétaire de ses propres user stories, qu’il doit couvrir par des cas de test et des scripts automatisés.

Cet usage a eu un effet direct sur la conception, et pas celui qu’on attendrait.

Un framework utilisé en formation est lu par des dizaines de personnes qui ne l’ont jamais vu, dans un temps contraint, et qui poseront la question « pourquoi c’est fait comme ça ? » à voix haute. Toute complexité non justifiable se signale immédiatement.

C’est un test de lisibilité qu’aucune revue de code interne ne remplace : en revue, on relit du code écrit par des gens qui partagent déjà nos hypothèses. En formation, personne ne les partage.

Plusieurs choix structurants de Pandora viennent directement de là. Non pas parce qu’ils étaient élégants, mais parce qu’ils étaient les seuls que l’on pouvait expliquer en quelques minutes à quelqu’un qui automatise pour la première fois.

Devriez-vous construire le vôtre ?

Dans la plupart des cas : non. Assemblez les briques standard, écrivez une couche d’objets de page correcte, gérez vos données proprement. Cela couvre l’immense majorité des besoins, et cela se maintient.

Envisagez-le si, et seulement si :

• vous avez une contrainte réellement spécifique que les outils génériques ignorent ;
• vous pouvez nommer les personnes qui le maintiendront dans trois ans ;
• vous acceptez de le documenter comme un produit ;
• vous savez dire ce qu’il impose et ce qu’il laisse libre.

Si vous ne pouvez pas répondre aux quatre, vous n’avez pas besoin d’un framework. Vous avez besoin d’appliquer les cinq décisions de structure qui font qu’une suite tient trois ans — et qui sont indépendantes de tout outil.

---

Le dépôt Pandora et sa documentation technique feront l’objet d’une publication distincte ; la fiche Pandora indique l’état courant. Cet article sera complété d’exemples concrets à ce moment-là.