Tests E2E dans WordPress Playground : des environnements jetables

Le jour de Noël, pendant que la majorité de l’équipe était en congé, on a profité du calme pour finaliser un chantier resté en attente depuis plusieurs mois : remplacer les conteneurs Docker un peu lourds utilisés pour les tests E2E par des instances WordPress Playground jetables, démarrées en quelques secondes directement dans le job de CI, sans image à construire ni base de données à provisionner manuellement.

WordPress Playground, ce moteur qui exécute WordPress entièrement dans un environnement WebAssembly sans serveur PHP traditionnel, n’est pas qu’une démo impressionnante pour tester rapidement un thème : couplé à wp-now pour un usage en ligne de commande, il devient un outil sérieux pour des tests E2E rapides à instancier, avec des garanties d’isolation que les conteneurs classiques peinent parfois à offrir aussi simplement.

Pourquoi des instances jetables changent la donne

Le problème récurrent avec des environnements de test partagés ou réutilisés d’une exécution à l’autre, c’est la contamination progressive : une option laissée en base par un test précédent, un utilisateur créé et jamais supprimé, un plugin resté activé, qui finissent par fausser les résultats de tests censés partir d’un état neutre. Une instance Playground démarrée à chaque exécution, entièrement en mémoire, élimine ce problème par construction : il n’y a littéralement rien à nettoyer entre deux exécutions, puisque rien ne persiste.

Décrire l’état initial avec un blueprint

Playground utilise des « blueprints », des fichiers JSON qui décrivent précisément l’état de départ souhaité : version de WordPress, extensions et thème à installer, contenus à créer, options à définir. Ce fichier se versionne avec le projet, au même titre que le code testé, ce qui rend l’environnement de test reproductible à l’identique par n’importe quel membre de l’équipe :

{
  "landingPage": "/wp-admin/",
  "preferredVersions": {
    "php": "8.2",
    "wp": "6.7"
  },
  "steps": [
    { "step": "login", "username": "admin", "password": "password" },
    {
      "step": "installPlugin",
      "pluginZipFile": { "resource": "url", "url": "https://example.test/mon-extension.zip" }
    },
    {
      "step": "runPHP",
      "code": "<?php wp_insert_post(['post_title' => 'Article de test E2E', 'post_status' => 'publish']);"
    }
  ]
}

Lancer wp-now depuis un job de CI

Pour un usage en ligne de commande, wp-now démarre une instance locale à partir d’un blueprint, sur un port dédié, ce qui permet de piloter le navigateur de test contre cette instance comme contre n’importe quel serveur WordPress classique :

npx @wp-now/wp-now start --blueprint=./tests/blueprint-e2e.json --port=8881 &
npx wait-on http://localhost:8881
npx playwright test --config=playwright.config.ts

Le temps de démarrage observé, sur les projets où on l’a mesuré, tourne autour de quelques secondes, nettement plus rapide qu’un conteneur Docker complet avec sa propre base MySQL à initialiser, ce qui réduit d’autant la durée totale du pipeline de CI sur des suites qui démarrent et arrêtent l’environnement plusieurs fois.

Les limites à connaître avant de tout migrer

Playground repose sur SQLite plutôt que sur MySQL par défaut, via le plugin d’intégration SQLite for WordPress. La grande majorité du code applicatif ne voit aucune différence, mais un test qui vérifierait explicitement une requête SQL brute écrite pour la syntaxe MySQL, ou qui dépendrait d’une fonctionnalité spécifique au moteur MySQL, ne peut pas se fier à ce type d’instance et doit rester sur un environnement MySQL classique.

Autre limite réelle : toute extension qui effectue de vrais appels réseau sortants, vers une passerelle de paiement ou une API tierce, ne peut pas être testée de façon fiable dans cet environnement sans mise en place d’un mock réseau, l’environnement WebAssembly imposant des contraintes spécifiques sur les requêtes HTTP sortantes selon le contexte d’exécution.

Cas d’usage à privilégier

• Tests d’interface d’administration d’une extension, sans dépendance réseau externe
• Tests de rendu d’un thème ou d’un bloc Gutenberg sur différents contenus de démonstration
• Vérification rapide de compatibilité d’une extension sur plusieurs versions de WordPress en parallèle, chaque instance démarrant avec sa propre version déclarée dans le blueprint

Paralléliser sur plusieurs versions de WordPress

L’un des bénéfices les plus concrets constatés : faire tourner la même suite E2E sur trois versions différentes de WordPress simultanément, chacune dans sa propre instance Playground jetable, simplement en changeant la valeur preferredVersions.wp du blueprint dans trois jobs de CI parallèles. Sur un projet d’extension distribuée publiquement, qui doit rester compatible avec les deux ou trois dernières versions majeures du cœur, cette matrice aurait demandé trois conteneurs Docker distincts à maintenir auparavant.

Un environnement de test qui ne laisse littéralement aucune trace derrière lui élimine une catégorie entière de bugs de tests, ceux qu’on croit provoqués par le code alors qu’ils viennent en réalité d’un résidu de l’exécution précédente.

En résumé

WordPress Playground et wp-now apportent une rapidité de démarrage et une isolation par construction qui simplifient réellement une suite E2E, en particulier pour des tests de matrice multi-versions ou des vérifications d’interface sans dépendance réseau. Ils ne remplacent pas totalement un environnement MySQL classique pour les projets qui en dépendent explicitement, ni les scénarios impliquant de vrais appels réseau sortants : le bon réflexe consiste à réserver Playground aux scénarios qui n’en ont pas besoin, et à garder un environnement traditionnel pour le reste.