Chapitre 11.3 — Tests (PHPUnit, Jest, e2e)

⏱️ TL;DR — Un plugin/thème sérieux est testé. Trois niveaux : PHPUnit pour le PHP (avec la suite de tests WordPress, via wp-env), Jest pour le JS de vos blocs (@wordpress/scripts test-unit-js), et Playwright (ou @wordpress/e2e-test-utils-playwright) pour les tests end-to-end (parcours réels dans un WordPress lancé). Les tests fiabilisent votre code à travers les mises à jour de WordPress et rendent vos produits crédibles (Partie 13). L’outillage est fourni par @wordpress/scripts et wp-env.

🎯 Objectifs

• Écrire des tests PHPUnit pour du code WordPress.
• Tester le JS de blocs avec Jest.
• Automatiser un parcours e2e avec Playwright.
• Structurer une base de tests utile (pas dogmatique).

1. Les trois niveaux

• PHPUnit : teste la logique PHP (fonctions, classes, hooks) — souvent en intégration avec un WordPress de test (accès à WP_Query, DB…).
• Jest : teste le JS (composants de blocs, utilitaires) en isolation.
• e2e (Playwright) : lance un vrai WordPress et simule un utilisateur (créer un post, insérer un bloc, vérifier le rendu).

2. PHPUnit avec la suite WordPress

WordPress fournit une suite de tests (bibliothèque WP_UnitTestCase) qui charge WordPress et réinitialise la base entre les tests (transactions annulées). Avec wp-env (ch. 4.1), l’environnement de test est prêt :

class Test_WPR_Books extends WP_UnitTestCase {
 
    public function test_cpt_est_enregistre() {
        $this->assertTrue( post_type_exists( 'livre' ) );
    }
 
    public function test_prix_est_sauvegarde() {
        $id = self::factory()->post->create( array( 'post_type' => 'livre' ) );
        update_post_meta( $id, 'wpr_prix', '19.90' );
        $this->assertSame( '19.90', get_post_meta( $id, 'wpr_prix', true ) );
    }
}

• WP_UnitTestCase : base de test qui isole chaque test (rollback DB).
• self::factory() : des générateurs de données (posts, users, terms) — comme des factories de test.
• Lancement : wp-env run tests-cli --env-cwd=wp-content/plugins/wpr-books vendor/bin/phpunit (ou un script npm/composer).

⚠️ Piège n°1 — tester sans réinitialiser la base. Sans la suite WordPress (WP_UnitTestCase), vos tests polluent la base et deviennent dépendants de l’ordre. Utilisez la suite officielle (rollback automatique) ou wp-env’s tests-cli, qui fournit une base de test propre.

3. Jest pour le JS des blocs

@wordpress/scripts inclut Jest préconfiguré :

npm run test:unit        # (mappe wp-scripts test-unit-js)

// src/utils.test.js
import { formatPrix } from './utils';
 
test( 'formatte un prix en euros', () => {
    expect( formatPrix( 19.9 ) ).toBe( '19,90 €' );
} );

Pour tester un composant de bloc, on utilise @testing-library/react (les composants Gutenberg sont du React, ch. 8) — mocker @wordpress/data/api-fetch au besoin. On teste la logique et le rendu, pas l’éditeur entier (c’est le rôle des e2e).

4. e2e avec Playwright

Les tests end-to-end lancent un WordPress réel et automatisent le navigateur. WordPress fournit des utilitaires Playwright (@wordpress/e2e-test-utils-playwright) :

import { test, expect } from '@wordpress/e2e-test-utils-playwright';
 
test( 'insérer le bloc Livre à la une', async ( { admin, editor } ) => {
    await admin.createNewPost();
    await editor.insertBlock( { name: 'wpr/livre-une' } );
    await expect( editor.canvas.getByText( 'Choisissez un livre' ) ).toBeVisible();
} );

Les e2e sont plus lents mais couvrent les parcours réels (ce que l’unitaire ne voit pas). On les réserve aux flux critiques (insertion d’un bloc, checkout, formulaire).

⚠️ Piège n°2 — tout tester en e2e. Les e2e sont lents et fragiles (dépendent de l’UI). Testez la logique en unitaire (PHPUnit/Jest, rapides) et gardez l’e2e pour quelques parcours clés. Une pyramide de tests saine : beaucoup d’unitaires, quelques e2e.

5. Que tester (pragmatique)

• La logique métier (calculs, validations, transformations) — le meilleur ROI.
• Les hooks critiques (le CPT est enregistré, la meta est exposée, la sécurité bloque).
• Les régressions : quand un bug est trouvé, écrire un test qui le reproduit avant de corriger.
• Les parcours critiques en e2e (1 à quelques-uns).

Ne visez pas 100 % de couverture dogmatique : visez la confiance sur ce qui compte et ce qui casse le plus.

💡 Pour un dev React — Vous êtes en terrain connu : Jest pour le JS, Testing Library pour les composants, Playwright pour l’e2e. La nouveauté est PHPUnit + la suite WordPress (factories, rollback DB, chargement de WP) — mais le concept (arrange/act/assert, factories, isolation) est identique. Des plugins testés + CI verte (ch. 11.4) sont un argument de vente fort (crédibilité, maintenance, marketplace).

✏️ Exercices

1. Quel outil pour tester qu’un CPT est bien enregistré et que sa meta se sauvegarde ?
2. Pourquoi réserver l’e2e à quelques parcours critiques ?
3. Vous découvrez un bug de calcul de prix. Quelle est la bonne démarche de test ?

🧠 Quiz de révision

Chapitre suivant : Standards de code & CI/CD.