PrestaFlow sans Flashlight : brancher sur sa stack locale

Décor

La série a supposé Flashlight partout — image Docker PrestaShop clé en main, jetable, idéale pour le CI. C’est le bon choix dès qu’on parle de reproductibilité (article 2) ou de matrice multi-versions.

Mais dans la vraie vie du dev, beaucoup de gens ont déjà une boutique qui tourne en local via Valet, MAMP, DevKinsta, Herd, ou une docker-compose.yml maison. Une boutique qui a leur config à eux, leur thème custom, leur base peuplée. Booter Flashlight à côté ferait doublon — voire noierait le vrai contexte de dev.

PrestaFlow se fiche royalement de savoir où la boutique tourne. Il lui faut juste une URL qui répond. Cette annexe montre comment le brancher sur votre stack existante, en une paire de lignes de .env, et quand ce choix est le bon.

La configuration minimale

Reprenons le .env de l’article d’introduction — mais cette fois, on pointe sur une boutique locale déjà installée, par exemple https://prestashop.test servi par Laravel Valet :

PRESTAFLOW_PS_VERSION=8.1.7
PRESTAFLOW_LOCALE=fr
PRESTAFLOW_FO_URL=https://prestashop.test/
PRESTAFLOW_BO_URL=https://prestashop.test/admin-dev/
PRESTAFLOW_BO_EMAIL=demo@prestashop.com
PRESTAFLOW_BO_PASSWD="Correct Horse Battery Staple"
PRESTAFLOW_HEADLESS=false

C’est tout. Vous lancez :

./vendor/bin/prestaflow run tests/prestaflow

Vos suites tournent contre prestashop.test — la boutique qui tourne déjà sur votre machine, avec sa config, ses modules installés, ses données. Pas de conteneur démarré, pas d’attente de boot.

Ce que ce mode donne (et ne donne pas)

Les gains

Zéro attente de boot. Un run PrestaFlow local démarre en une seconde, contre 30-60s pour Flashlight au premier boot.
Contexte de dev réaliste. Votre thème custom, vos modules installés, votre config personnalisée, votre catalogue à vous. Vous testez ce que vous développez, pas ce qu’un conteneur générique aurait servi.
Persistance entre runs. Un produit ajouté au panier persiste, une config modifiée reste. Utile pour explorer manuellement l’état laissé par un scénario, sans qu’un conteneur ne le jette derrière vous.
Vitesse d’itération. Combiné à PRESTAFLOW_HEADLESS=false et à l’app PrestaFlow, on obtient la boucle courte parfaite pour écrire un scénario en tâtonnant.

Les pertes

Reproductibilité perdue. Votre boutique a votre config, votre catalogue, votre base. Ce qui passe chez vous ne passera pas forcément chez le collègue — ni sur la CI. C’est le miroir inversé de la promesse Flashlight.
Pollution de la base. Vos suites laissent des traces (produits créés, adresses saisies, abonnements newsletter). Sans cleanup soigné (voir l’annexe module tiers sur le suffixe timestamp et le cleanup end-of-suite), la base grossit et se dégrade.
Impossible en CI. Sur GitHub Actions, il n’y a pas de prestashop.test — il faut soit Flashlight, soit monter une boutique dans le workflow.

Quand choisir Flashlight, quand choisir sa stack locale

Un cadre simple :

Moment	Bon choix
Écriture d’un scénario, itération rapide	Stack locale — boot en 1s, votre contexte
Debug d’un scénario capricieux	Stack locale — headed + persistance = pratique
Test avant push	Stack locale puis Flashlight — d’abord chez soi, puis le CI
CI sur chaque push	Flashlight — reproductibilité, matrice versions
Test multi-versions PrestaShop	Flashlight — l’input `ps-version` de l’Action
Démo à un collègue distant	Flashlight — il obtient le même résultat que vous

Autrement dit : les deux ne s’opposent pas, ils se complètent. La stack locale sert la boucle courte du dev, Flashlight sert le filet de sécurité partagé.

Combiner les deux modes dans un même projet

Rien n’empêche d’avoir les deux prêts, chacun avec son .env :

psflowdemo/
├─ .env                  ← local, .gitignored, pointe sur prestashop.test
├─ .env.flashlight       ← versionné, pointe sur http://localhost/ (Flashlight)

En local vous laissez PrestaFlow lire .env par défaut. En CI, la GitHub Action met l’environnement en dur via env: dans le workflow, ou vous copiez .env.flashlight en .env dans un step préalable.

Interaction avec les autres annexes

Cookies pré-injectés — récupérer le cookie de session admin de votre stack locale est trivial (DevTools sur la page BO ouverte à la main). Copier-coller dans PRESTAFLOW_COOKIES, et vos suites BO démarrent déjà connectées.
Preprod htpasswd — si votre stack locale est protégée par un htpasswd (cas rare mais possible pour partager une instance de dev entre plusieurs personnes), PRESTAFLOW_BASIC_* s’applique à l’identique.
Fixtures — les init-scripts Flashlight ne s’appliquent pas ici (pas de conteneur), le niveau 1 disparaît. Les niveaux 2 (step pré-run) et 3 (override before()) restent pertinents pour maintenir un état stable sur votre boutique locale.