Piloter ses tests depuis l'application PrestaFlow

Préambule

Les deux articles précédents nous ont donné les deux modes d’usage naturels de PrestaFlow :

Article 1 — la librairie PHP : on écrit ses scénarios et on les lance à la main avec ./vendor/bin/prestaflow run.
Article 2 — la GitHub Action : on délègue cette exécution à GitHub Actions à chaque commit, avec matrice multi-versions PS et remontées sur la plateforme.

Il reste un troisième mode d’usage, plus interactif : piloter ses scénarios depuis une interface graphique, en boucle courte, pendant le développement. C’est ce que fait l’application desktop PrestaFlow.

Ce n’est pas un remplaçant de la CLI ni du CI — c’est un complément, pensé pour les moments où on écrit un scénario, on l’ajuste, on relance, on regarde une capture, on ajuste encore. Là où repasser par le terminal casse le flux.

L’app en un paragraphe

L’application PrestaFlow est un desktop app construit avec NativePHP et Laravel. Elle tourne localement sur votre machine, lit vos projets PrestaFlow (le module et son dossier tests/prestaflow/), exécute les suites via un runner interne (elle instancie les classes TestsSuite directement en PHP, pas de shell-out vers la CLI) et affiche les résultats dans une UI dédiée. Un sync cloud optionnel pousse les runs vers prestaflow.io pour l’historique et les tableaux de bord.

Accès à la beta privée

Pour demander l’accès, contactez l’équipe PrestaFlow via le formulaire de contact sur prestaflow.io. Vous recevrez en retour :

un lien de téléchargement vers le .dmg de la dernière version,
un accès à votre espace sur prestaflow.io (utile plus tard pour le sync cloud).

Installation classique : ouvrir le .dmg, glisser l’app dans /Applications, premier lancement.

Premier lancement — connecter son compte

Au premier démarrage, l’app demande de se connecter avec les identifiants prestaflow.io. Deux méthodes disponibles :

Sign-in GitHub — flux OAuth classique, redirection navigateur.
Email + mot de passe — l’espace créé lors de la demande d’accès.

Une fois authentifié, un fichier .deviceToken est créé dans le dossier user-data de NativePHP (~/Library/Application Support/PrestaFlow/ sur Mac). C’est ce jeton qui sera utilisé pour toutes les interactions futures avec la plateforme.

Ajouter psflowdemo comme projet local

L’app fonctionne autour de la notion de projet local : un dossier sur votre disque qui contient un module PrestaShop équipé de PrestaFlow (typiquement le résultat des articles 1 et 2).

Depuis l’écran principal, Add project ouvre un sélecteur de dossier. Pointez sur la racine du module psflowdemo — celle qui contient composer.json, .env et tests/prestaflow/.

L’app scanne l’arborescence, détecte :

les suites dans tests/prestaflow/Suites/ (dans notre cas : Checkout, DisplayHome, UpdateTitle),
les Pages custom dans tests/prestaflow/Pages/ (notre Modules\Psflowdemo\Home),
les paramètres du .env (URLs BO/FO, credentials, locale).

Le projet apparaît dans la sidebar. La vue projet liste vos suites, chacune avec son statut du dernier run (jamais joué / passé / échoué).

Vue projet psflowdemo avec les trois suites détectées

Exécuter une suite depuis l’UI

Un clic sur une suite ouvre sa vue de détail. Un bouton Run en tête déclenche l’exécution.

Sous le capot, l’app dispatche un job Laravel (ExecuteSuite) qui instancie la classe TestsSuite de votre suite avec les settings (URLs, credentials, locale) lus depuis le .env, puis appelle ->run(cli: false). Pas de shell-out, pas de sous-processus PHP : l’app est l’exécuteur.

Concrètement, ça veut dire :

l’app pilote Chrome (via chrome-php/chrome, la même dépendance que la CLI),
les étapes s’exécutent une à une,
l’UI affiche la progression au fil de l’eau : étape en cours, étapes passées avec leur durée, échec éventuel.

Exécution en cours d'une suite avec progression étape par étape

En fin de run, la vue résultat s’affiche automatiquement.

Lire un résultat

La vue résultat est le point central de l’app. Elle affiche, pour un run donné :

La liste des étapes avec leur statut (vert / rouge / gris pour skipped ou todo) et leur durée individuelle.
La capture prise à chaque étape, cliquable pour l’agrandir. Quand une étape échoue, c’est la capture juste avant l’assertion qui s’affiche — souvent suffisante pour comprendre.
Le stack trace en cas d’exception, avec pointeur sur le fichier de la Page ou du Scenario.
Les stats du run : passes / failures / skips / durée totale.

Vue détaillée d'un run avec captures et statuts

L’app conserve un historique local de tous les runs joués depuis qu’elle est installée. On peut y revenir à tout moment via la sidebar : rouvrir un run d’hier, regarder sa capture, puis rebasculer sur le run d’aujourd’hui pour voir ce qui a changé quand quelque chose se met à casser.

Sync cloud — lier le projet à prestaflow.io

Tant qu’on reste local, l’app est autonome. Mais si vous utilisez déjà la plateforme (parce que vous avez suivi l’article 2 et branché l’Action GitHub), il devient intéressant de faire remonter vos runs locaux au même endroit — pour avoir tout l’historique (local + CI) sur le même dashboard.

Deux étapes de config, une fois par projet.

Activer le sync globalement

Ouvrez Settings → Cloud et activez Enable cloud sync. C’est un interrupteur global de l’app : tant qu’il est off, aucun run ne quitte votre machine.

Lier le projet local au projet cloud

Depuis la page Settings du projet psflowdemo (sidebar → projet → Settings), cliquez sur Link to cloud project dans la carte Cloud link. Une modale affiche la liste de vos projets prestaflow.io — c’est la même liste que celle utilisée pour l’Action GitHub, avec les mêmes Product Keys pk_....

Sélectionnez le projet correspondant. La Product Key est stockée localement, dans la config du projet.

Liaison du projet local à un projet cloud

Pousser un run vers la plateforme

Une fois le projet lié, chaque vue de run expose un bouton Sync now.

Un clic pousse le run (résultats, captures, régressions visuelles s’il y en a) vers l’API api.prestaflow.io. Le bouton se transforme en ✓ Synced — Open on prestaflow.io en cas de succès, en ✗ Failed — Retry avec l’erreur en tooltip sinon.

Bouton de sync sur la vue résultat, avant et après

Côté plateforme, le run apparaît dans l’historique du projet, aligné avec les runs remontés par l’Action GitHub. C’est là que la trilogie boucle : que vous testiez à la main (app), en local (CLI) ou en CI (Action), tout converge vers la même timeline. La sidebar de l’app signale les échecs de sync via un compteur ⟳ Sync failed (N) pour éviter que des runs restent oubliés en local.

Où l’app se positionne par rapport au reste

Les trois modes d’usage ne se remplacent pas — ils couvrent trois moments différents du cycle de développement d’un module :

CLI : le mode reproductible. Ce qui se joue en CI se joue à l’identique en local. Pas de dépendance graphique, scriptable, versionnable.
CI (Action GitHub) : le mode automatique. Chaque commit est testé sur chaque version PS supportée, sans intervention.
App : le mode interactif. Boucle courte pendant l’écriture d’un scénario, historique local, sync vers la plateforme quand on veut consolider.

Un dev qui publie des modules open-source va typiquement utiliser les trois : app pour écrire et itérer, CI pour le filet de sécurité, CLI en dépannage ponctuel ou en environnement contraint.

Notes

Vous avez maintenant les trois pièces : lib, CI, app. La série continue par des annexes plus courtes centrées sur des cas d’usage précis — factoriser ses Pages entre plusieurs suites, tester un module tiers dont on n’est pas l’auteur, exploiter les régressions visuelles, gérer les scénarios multi-versions PrestaShop. À suivre.