Le framework
Pandora est un modèle, pas une boîte noire.
Construire son propre framework d’automatisation est, presque toujours, une mauvaise idée. Nous l’avons fait quand même — pour une raison précise, et en acceptant ce que cela impose.
Un outil fait quelque chose à votre place : il gagne du temps et 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 d’être lu. Pandora est de la seconde catégorie, parce qu’il sert à la fois nos missions d’industrialisation et le support technique de nos formations.
Ce que nous ne montrons pas encore
Le dépôt Pandora et sa documentation technique feront l’objet d’une publication distincte. Tant que ce n’est pas le cas, cette page décrit des principes d’architecture, pas une référence d’usage : nous n’illustrons aucune API avant qu’elle ne soit publiquement consultable.
C’est une gêne commerciale assumée. Publier des extraits d’une interface qui peut encore changer produirait exactement la documentation périmée que nous reprochons aux frameworks maison.
Trois conséquences concrètes
Un framework destiné à être lu ne se conçoit pas comme un framework destiné à être utilisé.
- D1
Explicite plutôt que magique
Quelques lignes lisibles valent mieux qu’une couche d’abstraction qui devine. La configuration par convention est confortable jusqu’au jour où l’on veut en sortir.
- D2
Les briques restent apparentes
On écrit du Selenium et du TestNG, pas un langage intermédiaire. Ce qui est appris reste utile ailleurs — y compris après avoir quitté Pandora.
- D3
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 une exigence structurante, pas un ajout.
Ce qu’il impose, ce qu’il laisse libre
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.
Imposé
- 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.
Laissé 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.
Devriez-vous construire le vôtre ?
Dans la plupart des cas, non. L’article détaille les quatre conditions auxquelles la réponse change, et ce qu’un framework doit imposer plutôt que laisser libre.