Étude de cas
Une suite. Trois versions de PrestaShop.
1.7, 8, 9 — la même boutique, la même suite de tests. Ce que PrestaFlow absorbe des sauts de version, et ce que ça libère côté scénarios, datasets, params et rapports.
La boutique
Une boutique PrestaShop. Elle tourne en 1.7 aujourd'hui. Elle passera en 8 dans quelques mois, puis en 9. Peut-être qu'elle tourne déjà en 8 sur un domaine parallèle, ou que c'est un module vendu à des clients répartis sur les trois versions. Peu importe : ce qu'elle veut, c'est être testée sans qu'on récrive la suite à chaque saut de version.
Ce qui change entre 1.7 et 9
Le BackOffice a été refondu. Les sélecteurs FrontOffice ont bougé sur le tunnel invité et sur la fiche produit. Certaines URLs ont changé, des modules natifs ont été remplacés, la structure du DOM du header n'est plus la même. Écrire une suite de tests contre ces trois cibles à la main, c'est trois suites qui divergent — et une charge de maintenance qui rend le projet impossible à tenir.
PrestaFlow absorbe ces différences via des Page objects par version (Pages/v7, Pages/v8, Pages/v9) et une auto-détection à l'exécution. Le scénario que tu écris ne sait pas — n'a pas besoin de savoir — sur quelle version il tourne. Il demande « ouvrir la fiche produit », « ajouter au panier », « valider le tunnel invité » ; la lib traduit vers les bons sélecteurs de la version détectée.
Ce que tu écris
Scénarios
it/expect à la Jest. Un scénario chaîne BackOffice puis FrontOffice dans une même suite — créer un produit en BO, l'acheter en FO invité, vérifier la commande en BO. Une API d'actions lisible qui masque l'orchestration Chrome DevTools Protocol.
Datasets
Produits, clients, adresses, panier — définis une fois, rejouables partout. Les jeux de données vivent hors du code des scénarios, donc régénérer un compte de test ou changer d'adresse de livraison ne casse aucune assertion.
Params
.env par environnement, presets HTTP (Basic Auth, cookies pré-injectés, User-Agent), headless ou headed, --file pour cibler un seul scénario, taille de fenêtre configurable. Ce qui varie entre local et CI se pilote sans toucher au code.
Rapports
Sortie console, --output=JSON, JUnit XML pour la CI, --visual-report pour le HTML de régression visuelle. Chaque erreur pointe le scénario, le step, la version cible et — si visuelle — la capture diff référence/actuel.
Deux façons de l'exploiter
Marchand — matrice temporelle. Ta suite tourne aujourd'hui contre ta 1.7 en production, contre ta 8 en staging pré-migration, contre une 9 sur environnement de test. Quand les trois passent au vert, la migration est mûre. Après le basculement, la même suite continue en monitoring — pas de récriture.
Éditeur de module — matrice parallèle.
À chaque release de ton module, la même suite est jouée sur 1.7, 8 et 9 en simultané via strategy.matrix côté CI. Une seule case rouge suffit à bloquer la publication. Tes clients sur toutes les versions supportées sont couverts par la même vérification.
Le résultat
Une seule suite. Trois versions cibles. Le coût d'écriture d'un test n'est plus multiplié par le nombre de versions à supporter, il est payé une fois. Le coût de maintenance ne suit plus le cycle de release de PrestaShop : quand une v10 arrivera, la lib ajoutera Pages/v10 et ta suite tournera sans que tu la touches. Le test n'est plus un frein à la montée de version — c'est ce qui la rend possible.
Pour aller plus loin
- ➜ Installation — le point de départ, quelques minutes.
- ➜ Actions — l'API des scénarios que tu écris tous les jours.
- ➜ Presets HTTP — Basic Auth, cookies, User-Agent.
- ➜ Régression visuelle — checkpoints et baseline.
- ➜ GitHub Actions — patterns CI — la matrice de versions en pratique.
- ➜ Étude de cas : La Cité des Nuages — la même lib, appliquée au monitoring d'une boutique en production.
Et si cette boutique, c'était la tienne ?
PrestaFlow fonctionne contre n'importe quel environnement PrestaShop 1.7 → 9. Commencez par le guide d'installation.