Jest pour les blocs Gutenberg : tester vos composants React efficacement

Un bloc Gutenberg n’est jamais qu’un composant React, avec des fonctions edit et save, des contrôles dans la barre latérale, et parfois une logique de validation non triviale. Tester ce composant avec un test end-to-end complet, qui démarre un navigateur et une installation WordPress entière, fonctionne, mais reste lent et lourd pour vérifier une simple règle de rendu conditionnel. Jest, associé à Testing Library, permet de tester ce composant isolément, en quelques millisecondes par test.

Cet article détaille la mise en place de Jest sur un projet de blocs personnalisés, avec des exemples concrets de test de la fonction edit, des contrôles d’InspectorControls, et des pièges à éviter avec les snapshots.

Pourquoi Jest en complément des tests E2E

Les tests E2E avec Puppeteer, présentés dans un précédent article, valident qu’un bloc fonctionne réellement dans l’éditeur WordPress complet, avec toutes ses dépendances. Mais ils sont lents à écrire et à exécuter, et peu adaptés pour couvrir de nombreux cas limites d’un composant (props manquantes, valeurs invalides, états intermédiaires). Jest, en testant le composant React directement, sans monter tout l’éditeur, comble cet écart : une suite de cinquante tests Jest sur la logique d’un bloc s’exécute en quelques secondes, contre plusieurs minutes pour l’équivalent en E2E.

Installer Jest avec le préréglage WordPress

npm install --save-dev jest @wordpress/jest-preset-default @testing-library/react

Le paquet @wordpress/jest-preset-default configure automatiquement les transformations nécessaires pour JSX et les modules ES, ainsi que des mocks par défaut pour certains modules WordPress difficiles à charger tels quels dans un environnement de test Node.js. Un fichier jest.config.js dédié aux tests unitaires, distinct de la configuration E2E, ressemble à ceci :

module.exports = {
    preset: '@wordpress/jest-preset-default',
    testPathIgnorePatterns: [ '/node_modules/', '/tests/e2e/' ],
};

Tester la fonction edit d’un bloc

Supposons un bloc simple qui affiche un titre et un sous-titre modifiables. Sa fonction edit ressemble à ceci, simplifiée pour l’exemple :

export default function Edit( { attributes, setAttributes } ) {
    const { titre, sousTitre } = attributes;

    return (
        <div { ...useBlockProps() }>
            <RichText
                tagName="h2"
                value={ titre }
                onChange={ ( value ) => setAttributes( { titre: value } ) }
                placeholder="Titre de la section"
            />
            <RichText
                tagName="p"
                value={ sousTitre }
                onChange={ ( value ) => setAttributes( { sousTitre: value } ) }
                placeholder="Sous-titre"
            />
        </div>
    );
}

Avec Testing Library, on vérifie que les valeurs initiales s’affichent et que la saisie déclenche correctement setAttributes :

import { render, screen } from '@testing-library/react';
import Edit from '../edit';

describe( 'Bloc Section titrée - edit', () => {
    it( 'affiche le titre existant', () => {
        render(
            <Edit
                attributes={ { titre: 'Nos services', sousTitre: '' } }
                setAttributes={ jest.fn() }
            />
        );

        expect( screen.getByText( 'Nos services' ) ).toBeInTheDocument();
    } );
} );

Ce test ne dépend d’aucun serveur WordPress : il rend le composant React en mémoire, dans un DOM simulé par jsdom, et vérifie le résultat directement.

Tester une fonction de validation pure

La logique la plus rentable à couvrir en Jest reste souvent la logique pure, indépendante du rendu, par exemple une fonction qui valide les attributs d’un bloc avant sauvegarde :

export function estAttributsValides( attributes ) {
    return typeof attributes.titre === 'string' && attributes.titre.trim().length > 0;
}

import { estAttributsValides } from '../validation';

describe( 'estAttributsValides', () => {
    it( 'refuse un titre vide', () => {
        expect( estAttributsValides( { titre: '   ' } ) ).toBe( false );
    } );

    it( 'accepte un titre renseigné', () => {
        expect( estAttributsValides( { titre: 'Nos services' } ) ).toBe( true );
    } );
} );

Snapshots : un outil à manier avec précaution

Jest propose un mécanisme de snapshot testing, qui capture le rendu d’un composant et le compare à une version enregistrée précédemment. Séduisant à première vue, il pose un vrai risque sur des composants qui évoluent souvent : un développeur pressé finit par accepter aveuglément chaque nouveau snapshot avec jest --updateSnapshot, ce qui vide le test de tout son sens.

• Réservez les snapshots à des composants stables, peu susceptibles de changer souvent.
• Préférez des assertions explicites (getByText, getByRole) pour la logique qui compte vraiment.
• Relisez systématiquement un diff de snapshot avant de l’accepter, plutôt que de le valider en masse.

Sur nos projets, nous limitons les snapshots aux blocs dont le HTML de sortie doit rester strictement stable pour des raisons de rétrocompatibilité de contenu. Pour tout le reste, une assertion explicite coûte à peine plus cher à écrire et reste bien plus lisible six mois plus tard.

En résumé

Jest et Testing Library comblent l’écart entre les tests end-to-end lourds et l’absence totale de test sur la logique d’un bloc Gutenberg. En couvrant la fonction edit, les contrôles associés et surtout la logique pure de validation, on obtient une suite rapide qui détecte l’essentiel des régressions avant même d’ouvrir un navigateur, tout en gardant les tests E2E pour les parcours critiques de bout en bout.