Case study
One suite. Three versions of PrestaShop.
1.7, 8, 9 — the same shop, the same test suite. What PrestaFlow absorbs from major-version jumps, and what it unlocks on the scenarios, datasets, params and reports side.
The shop
A PrestaShop shop. It runs on 1.7 today. It will move to 8 in a few months, then 9. Maybe it already runs on 8 on a parallel domain, or maybe it's a module sold to customers spread across all three versions. It doesn't matter: what it wants is to be tested without rewriting the whole suite at every version jump.
What changes between 1.7 and 9
The BackOffice has been rebuilt. FrontOffice selectors have moved on the guest checkout and the product page. Some URLs have changed, some native modules have been replaced, the header DOM is no longer the same. Writing a test suite against those three targets by hand means three suites that drift apart — and a maintenance load that makes the project impossible to sustain.
PrestaFlow absorbs those differences through per-version Page objects (Pages/v7, Pages/v8, Pages/v9) and runtime auto-detection. The scenario you write doesn't know — doesn't need to know — which version it runs against. It says "open the product page", "add to cart", "confirm the guest checkout"; the lib translates to the right selectors for the detected version.
What you write
Scenarios
it/expect in a Jest-like style. A scenario chains BackOffice then FrontOffice in a single suite — create a product in the BO, buy it as a guest on the FO, verify the order back in the BO. A readable actions API that hides the Chrome DevTools Protocol orchestration.
Datasets
Products, customers, addresses, cart — defined once, replayable everywhere. Datasets live outside the scenario code, so regenerating a test account or changing a delivery address breaks no assertion.
Params
.env per environment, HTTP presets (Basic Auth, pre-injected cookies, User-Agent), headless or headed, --file to target a single scenario, configurable window size. What varies between local and CI is driven without touching the code.
Reports
Console output, --output=JSON, JUnit XML for CI, --visual-report for the visual regression HTML. Every failure points at the scenario, the step, the target version and — if visual — the reference/actual diff.
Two ways to use it
Merchant — time matrix. Your suite runs today against your 1.7 in production, your 8 in pre-migration staging, and a 9 in a test environment. When all three go green, the migration is ripe. After the switch, the same suite keeps running as monitoring — no rewrite.
Module editor — parallel matrix.
Every release of your module has the same suite play on 1.7, 8 and 9 in parallel via strategy.matrix in CI. A single red cell is enough to block the release. Every customer on any supported version is covered by the same check.
The outcome
One suite. Three target versions. The write cost of a test is no longer multiplied by the number of versions to support — it's paid once. Maintenance no longer follows PrestaShop's release cycle: when a v10 arrives, the lib will add Pages/v10 and your suite will keep running untouched. Testing is no longer a brake on version upgrades — it's what makes them possible.
Learn more
- ➜ Installation — the starting point, a few minutes.
- ➜ Actions — the API you write scenarios with every day.
- ➜ HTTP presets — Basic Auth, cookies, User-Agent.
- ➜ Visual regression — checkpoints and baseline.
- ➜ GitHub Actions — CI patterns — the version matrix in practice.
- ➜ Case study: La Cité des Nuages — the same lib, applied to production monitoring of a live shop.
What if this shop were yours?
PrestaFlow runs against any PrestaShop 1.7 → 9 environment. Start with the installation guide.