Case study
How La Cité des Nuages catches regressions before customers do
Twice a day and after every deploy, an end-to-end suite validates the shop against its preproduction — with visual regression on the pages that matter.
The shop
La Cité des Nuages is a French-speaking Belgian PrestaShop merchant with a rich catalogue, custom modules and a preproduction environment protected by HTTP Basic Auth and a cookie-consent banner. The kind of setup that used to make automated end-to-end testing painful.
The problem
Every deployment carried a risk of silent regression somewhere in the FrontOffice: a broken guest checkout, a module page returning 500, a visual layout shift on the brand list. Manually walking through every critical path after each deploy was not sustainable — and when the check was skipped, customers found the bug before the team did.
The setup with PrestaFlow
A GitHub Actions workflow triggered on repository_dispatch: prod-deploy and on a schedule (twice a day, UTC). PrestaFlow runs against the preproduction shop — never against production.
One suite per module in a strategy.matrix with fail-fast: false: catalogue, guest checkout, customer account, brand pages, gift cards, pre-order product. Each suite runs on a fresh runner — a fresh browser — so a logged-in test can't inherit a guest cart.
Env-driven HTTP presets: PRESTAFLOW_BASIC_USER/_PASS for the preproduction, PRESTAFLOW_COOKIES to skip the cookie banner in one line of JSON, a realistic User-Agent so anti-bot filters don't fight the runner.
Visual regression on the critical pages — homepage, brand list, gift-card page, product detail. The baseline is frozen in actions/cache with a salt (VISUAL_BASELINE_VERSION), so refreshing it after an intentional change is a single-variable bump.
Each critical page is captured at three viewport sizes — desktop (1920×1080), tablet (768×1024), mobile (375×812) — via a second axis of the strategy.matrix. Every suite × size combination has its own baseline, so a mobile-only regression isn't drowned out by the desktop comparison.
What every run publishes
A JUnit XML report consumed by mikepenz/action-junit-report with require_tests: true. If the browser fails to start on a cold runner and nothing actually ran, the check turns red instead of silently passing.
A Job Summary directly on the run's page: a markdown table of every visual checkpoint with its pass/fail status and similarity score, generated from visual-results.json.
The full HTML visual regression report — reference, actual and diff side by side for every checkpoint — published on GitHub Pages from a companion public repository. Anyone on the team can open the link, no artifact download required.
The result
Deployment stopped being a leap of faith. When something visibly changes on a monitored page, the CI catches it — with a screenshot — before anyone opens the shop. When a critical path breaks, the check goes red within the hour, not with the next customer email. The team ships continuously, with the same confidence they used to have only for weekly-planned releases.
Read more
- ➜ HTTP presets — Basic Auth, cookies, User-Agent.
- ➜ Visual regression — the checkpoint API and the baseline workflow.
- ➜ GitHub Actions — CI patterns — the exact patterns used in this setup.
Try it on your shop
PrestaFlow works against any PrestaShop 1.7 → 9 environment. Start with the installation guide.