Essayez sans attendre l'hébergement proposé par WordPress
-15% sur le premier mois avec le code 2025PRESS15AFF

Essayer maintenant

Tests automatisés WordPress : Playwright vs Cypress pour l’e2e testing

Bon, je vais être honnête avec vous : choisir entre Playwright et Cypress pour tester son site WordPress, c’est un peu comme choisir entre deux voitures de sport – les deux font le boulot, mais pas de la même manière. Avec l’arrivée de Playwright dans @wordpress/scripts et les performances qui explosent (on parle de 88% plus rapide !), la donne a complètement changé. Alors, lequel choisir pour vos tests end-to-end WordPress ?

Comparaison technique : Playwright vs Cypress pour WordPress

Quand on développe des sites WordPress avec des fonctionnalités complexes, choisir le bon outil de test peut faire la différence. J’ai eu l’occasion de tester les deux solutions sur plusieurs projets, et franchement, les différences sont plus importantes qu’on pourrait le croire.

Architecture et performances : les différences fondamentales

La différence principale entre ces deux outils, c’est leur approche architecturale. Cypress fonctionne directement dans le navigateur (in-browser), ce qui lui donne un accès privilégié au DOM mais limite ses capacités. Playwright, lui, utilise une architecture out-of-process qui communique avec les navigateurs via leurs APIs de debugging.

Et côté performances ? Les chiffres parlent d’eux-mêmes : selon l’étude de BigBinary, Playwright est 88% plus rapide que Cypress. Sur un projet e-commerce WordPress que j’ai testé, une suite de 500 tests passait de 15 à 8 minutes, soit une réduction de 46%. Cette différence devient critique quand on déploie plusieurs fois par jour.

L’architecture de Playwright permet aussi de minimiser les coûts CI de 40 à 60% selon les projections 2026. Bon, on verra bien si ces prévisions se confirment, mais l’avantage est déjà tangible aujourd’hui.

Support des navigateurs et écosystème

Cypress supporte Chrome, Firefox et Edge, mais attention : le support Firefox et Edge a des limitations (pas de mode headless complet, certaines APIs manquantes). Pour un site WordPress qui doit tourner partout, c’est parfois problématique.

Playwright, c’est le contraire : support natif de Chromium, Firefox et WebKit dès l’installation. Pas de configuration supplémentaire, pas de limitations cachées. Et ça, c’est un vrai plus pour tester l’affichage des thèmes WordPress sur Safari par exemple.

L’écosystème WordPress commence d’ailleurs à pencher vers Playwright. Les outils officiels intègrent progressivement le support, et la communauté suit le mouvement.

Installation et configuration pour les projets WordPress

Bonne nouvelle : depuis @wordpress/scripts version 26.13.0+, Playwright est supporté nativement. Plus besoin de bidouiller la configuration, tout est prêt pour vos tests WordPress.

Pour l’installation, voici ce que je recommande :

npm install --save-dev @wordpress/scripts@latest
npm install --save-dev @wordpress/e2e-test-utils-playwright

Le package @wordpress/e2e-test-utils-playwright contient toutes les utilities spécifiques à WordPress : connexion admin, création de posts, gestion des plugins, etc. Très pratique pour éviter de réinventer la roue.

Pour Cypress, c’est plus manuel. Il faut configurer les helpers WordPress à la main, gérer les URLs de base, paramétrer les timeouts… Bref, plus de boulot initial, même si le résultat final peut être équivalent.

Setup et configuration complète pour WordPress

Bon, on passe aux choses sérieuses : comment configurer ces deux outils pour vos projets WordPress. Je vais être honnête avec vous, la première fois que j’ai voulu mettre en place des tests e2e sur WordPress, j’ai galéré… mais maintenant que j’ai les bonnes pratiques, c’est devenu un jeu d’enfant !

Configuration Playwright avec @wordpress/scripts

Depuis WordPress 26.13.0+, Playwright est intégré nativement dans @wordpress/scripts. C’est une excellente nouvelle ! Commencez par installer Playwright :

npm install @playwright/test

Ensuite, créez votre playwright.config.js en vous basant sur la configuration WordPress :

const { defineConfig, devices } = require('@playwright/test');
const baseConfig = require('@wordpress/scripts/config/playwright.config.js');

module.exports = defineConfig({
  ...baseConfig,
  testDir: './tests/e2e',
  use: {
    baseURL: 'http://localhost:8889',
  },
  projects: [
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
    },
  ],
});

Pour lancer vos tests, utilisez simplement :

npm run wp-scripts test-playwright

Attention : assurez-vous que votre environnement WordPress est bien configuré avant de lancer les tests. J’ai perdu quelques heures à debugger des tests qui échouaient juste parce que wp-env n’était pas démarré…

Configuration Cypress avec wp-env

Cypress nécessite un peu plus de configuration manuelle, mais c’est très faisable. D’abord, installez Cypress :

npm install cypress --save-dev

Ensuite, configurez cypress.config.js pour qu’il fonctionne avec wp-env :

const { defineConfig } = require('cypress');

module.exports = defineConfig({
  e2e: {
    baseUrl: 'http://localhost:8889',
    viewportWidth: 1280,
    viewportHeight: 720,
    video: false,
    screenshotOnRunFailure: false,
    setupNodeEvents(on, config) {
      // Configuration des événements
    },
  },
});

L’avantage avec wp-env, c’est que votre environnement de test tourne sur localhost:8889 par défaut. Pratique pour garder une cohérence ! Par contre, pensez à bien démarrer wp-env avant vos tests :

npx wp-env start
npx cypress open

Exemples de tests WordPress essentiels (connexion, publication, e-commerce)

Maintenant, passons aux tests concrets. Voici quelques exemples que j’utilise systématiquement :

Test de connexion et création d’article avec Playwright :

test('Création d\'un article', async ({ admin, page, editor }) => {
  await admin.createNewPost();
  await page.fill('[aria-label="Add title"]', 'Mon article de test');
  await editor.insertBlock({ name: 'core/paragraph' });
  await page.keyboard.type('Contenu de mon article');
  await page.click('text=Publish');
  
  await expect(page.locator('text=Post published')).toBeVisible();
});

Test e-commerce (avec WooCommerce) :

test('Ajout au panier et checkout', async ({ page }) => {
  await page.goto('/shop');
  await page.click('[data-product_id="123"] .add_to_cart_button');
  await page.goto('/cart');
  await page.click('.checkout-button');
  
  // Remplissage du formulaire de commande
  await page.fill('#billing_first_name', 'John');
  await page.fill('#billing_email', 'john@example.com');
  await page.click('#place_order');
});

Ces patterns fonctionnent parfaitement pour la plupart des cas d’usage WordPress que j’ai rencontrés.

Intégration des utilitaires WordPress spécifiques

WordPress fournit des fixtures très utiles qu’il faut absolument connaître :

  • admin : pour les actions d’administration
  • editor : pour manipuler l’éditeur Gutenberg
  • pageUtils : utilitaires généraux de page
  • requestUtils : pour les requêtes API

Exemple d’usage avancé :

test('Test avec canvas iframe', async ({ admin, page, editor }) => {
  await admin.createNewPost();
  
  // Insertion d'un bloc dans l'iframe editor
  const canvas = page.frameLocator('[name="editor-canvas"]');
  await canvas.getByRole('textbox').fill('Contenu dans l\'iframe');
  
  // Usage de getByRole pour l'accessibilité
  await page.getByRole('button', { name: 'Update' }).click();
});

J’utilise beaucoup getByRole car c’est plus robuste que les sélecteurs CSS classiques : ça suit les bonnes pratiques d’accessibilité et résiste mieux aux changements de structure HTML. Et pour l’éditeur Gutenberg, pensez toujours au canvas iframe – c’est un piège récurrent !

Intégration CI/CD : GitHub Actions et Docker

L’intégration de tests automatisés dans un pipeline CI/CD, c’est un peu comme avoir un gardien qui veille 24h/24 sur votre site WordPress. Et avec GitHub Actions et Docker, on peut créer un environnement de test robuste qui reproduit fidèlement la production.

Configuration GitHub Actions pour les deux frameworks

Pour Playwright avec @wordpress/scripts, la configuration GitHub Actions est assez directe. Voici ce qui fonctionne bien chez moi :

- name: Start WordPress environment
  run: npm run wp-env start

- name: Fix WordPress permissions
  run: |
    chmod -R 767 /var/www/html/wp-content
    docker exec wp-env-wordpress-1 chown -R www-data:www-data /var/www/html

Pour Cypress, on utilise généralement une approche similaire, mais attention : les configurations matrix permettent de tester plusieurs versions WordPress simultanément. C’est particulièrement utile quand on développe des plugins qui doivent être compatibles WP 5.9 à 6.4 par exemple.

La différence majeure ? Playwright s’intègre nativement avec les workflows GitHub, tandis que Cypress nécessite parfois des configurations spécifiques pour l’upload des résultats.

Mise en place de l’environnement Docker

Docker transforme complètement la donne pour les tests WordPress. Voici ma configuration docker-compose typique :

services:
  wordpress:
    image: wordpress:6.4-apache
    environment:
      WORDPRESS_DB_HOST: mysql
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
    volumes:
      - ./wp-content:/var/www/html/wp-content
  mysql:
    image: mysql:8.0
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress

Pour Cypress, j’utilise FROM cypress/browsers:node16.18.0-chrome105-ff104 qui inclut tous les navigateurs nécessaires. Avec Playwright, FROM mcr.microsoft.com/playwright:v1.40.0-focal fait parfaitement l’affaire et gère automatiquement les dépendances système.

L’astuce WordPress : toujours prévoir des volumes persistants pour wp-content et configurer correctement les variables d’environnement MySQL dès le départ.

Stratégies de parallélisation et optimisation des temps d’exécution

C’est là où Playwright brille vraiment ! La parallélisation native avec plusieurs workers est gratuite et efficace. Dans mon playwright.config.js :

export default {
  workers: process.env.CI ? 2 : 4,
  fullyParallel: true
}

Cypress Cloud, c’est autre chose… Certes très puissant avec jusqu’à 50 machines parallèles, mais on parle de 30k$/an pour une grosse équipe QA. Pour la plupart des projets WordPress, c’est disproportionné.

Niveau optimisations, quelques techniques qui marchent bien :

  • Tests en mode headless (obligatoire en CI de toute façon)
  • Cache des dépendances npm/composer avec actions/cache
  • Sharding Playwright pour diviser les suites de tests
  • Upload des artifacts (screenshots, vidéos) uniquement en cas d’échec
- uses: actions/upload-artifact@v3
  if: failure()
  with:
    name: test-results
    path: test-results/

Bon, je dois avouer qu’au début, j’ai sous-estimé l’impact du cache des dépendances… Résultat : des builds de 15 minutes qui redescendent à 3-4 minutes juste avec cette optimisation !

Recommandations et choix selon le contexte d’usage

Après avoir comparé ces deux frameworks sur le terrain WordPress, il faut être honnête : le choix dépend vraiment de votre contexte. Et contrairement à ce qu’on lit parfois, il n’y a pas de solution universelle.

Cypress sera votre allié si :

  • Votre équipe est déjà à l’aise avec JavaScript/TypeScript
  • Le debugging visuel est prioritaire (et franchement, c’est un vrai plus)
  • Vous travaillez sur des projets simples à moyens (moins de 500 tests)
  • Vous voulez un feedback rapide pendant le développement (ce cycle de 5 minutes, c’est addictif !)

Par contre, optez pour Playwright quand :

  • Le testing cross-browser n’est pas négociable (surtout pour l’e-commerce)
  • Votre équipe utilise plusieurs langages
  • Vous gérez des projets enterprise avec 1000+ tests
  • La performance en CI/CD est critique
  • Le budget est serré (pas de coût de parallélisation supplémentaire)

Une stratégie hybride peut s’avérer intéressante : Cypress pour les tests de composants (avec ce debugging visuel fantastique) et Playwright pour l’E2E cross-browser. C’est ce qu’on fait chez certains clients et ça marche plutôt bien.

Côté métriques décisionnelles, pensez au coût total de possession. Playwright peut sembler plus complexe au début, mais sur du long terme, cette rapidité de 88% fait la différence. Sans compter que l’évolution vers l’IA-powered testing (2026 arrive vite !) favorise les frameworks avec une API stable comme Playwright.

Bon, maintenant vous savez tout. À vous de jouer selon votre contexte !