# Tester l’éditeur de site : theme.json et blocs à l’ère de la FSE

> Depuis WordPress 5.9, un thème bloc repose sur theme.json et des modèles HTML plutôt que sur des fichiers PHP classiques. Voici comment adapter votre stratégie de tests à ce nouveau paradigme.

- Auteur : Clément Hadrot
- Publié le : 2022-08-24
- Mis à jour le : 2022-08-24
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/tester-fse-theme-json-blocs/

## L’essentiel

- theme.json testé comme un simple document JSON structuré
- Des tests E2E sur les modèles de blocs plutôt que sur les fichiers PHP
- Une checklist pour couvrir un thème bloc sans se noyer

WordPress 5.9, sorti en janvier dernier, a généralisé l'édition complète de site, et WordPress 6.0, sorti en mai, en a consolidé les bases. Un thème compatible FSE ne ressemble plus à un thème classique : plus de `header.php` ni de `footer.php` à proprement parler, mais des modèles HTML au format bloc, et un fichier central, `theme.json`, qui définit la palette de couleurs, la typographie et les espacements disponibles dans l'éditeur. Cette architecture change en profondeur la façon de tester un thème.

Nous avons accompagné plusieurs clients dans la construction de leurs premiers thèmes blocs ces derniers mois, et voici la stratégie de test que nous avons progressivement mise en place, entre validation du fichier `theme.json`, tests E2E sur les modèles, et ce qu'il ne sert à rien de tester à ce stade encore jeune de la fonctionnalité.

## theme.json : un document à valider comme n'importe quel JSON structuré

Le fichier `theme.json` suit un schéma précis, publié par l'équipe cœur, qui définit les clés autorisées et leur structure attendue. Une première ligne de défense simple consiste à valider ce fichier contre son schéma officiel dans la CI, avant même de lancer un test plus poussé :

```
{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 2,
  "settings": {
    "color": {
      "palette": [
        { "slug": "primaire", "color": "#1e3a5f", "name": "Primaire" },
        { "slug": "secondaire", "color": "#f2994a", "name": "Secondaire" }
      ]
    }
  }
}
```

Un outil de validation JSON Schema générique (comme `ajv-cli` côté Node.js) suffit à détecter une clé mal orthographiée ou une valeur du mauvais type, avant que l'erreur ne se manifeste silencieusement dans l'éditeur, où `theme.json` mal formé est simplement ignoré en partie sans message d'erreur clair pour l'utilisateur final.

## Tester la génération des styles avec PHPUnit

Le cœur WordPress expose des fonctions pour interroger les réglages effectifs issus de `theme.json`, notamment via la classe `WP_Theme_JSON_Resolver`. Un test PHPUnit peut vérifier que la palette de couleurs déclarée est bien celle exposée à l'éditeur :

```
class Test_Theme_Json extends WP_UnitTestCase {

    public function test_la_palette_contient_la_couleur_primaire() {
        $donnees = WP_Theme_JSON_Resolver::get_merged_data();
        $palette = $donnees->get_settings()['color']['palette']['theme'];

        $slugs = wp_list_pluck( $palette, 'slug' );

        $this->assertContains( 'primaire', $slugs );
    }
}
```

Ce type de test protège contre une régression silencieuse : un développeur qui renomme un slug de couleur dans `theme.json` casse potentiellement tous les blocs existants qui référencent cette couleur, sans qu'aucune erreur PHP ne se déclenche.

> L'essentiel à retenir : theme.json testé comme un simple document JSON structuré ; Des tests E2E sur les modèles de blocs plutôt que sur les fichiers PHP ; Une checklist pour couvrir un thème bloc sans se noyer

## Tester les modèles de blocs avec des tests E2E

Les modèles (`templates/single.html`, `templates/archive.html`...) et les parties de modèles (`parts/header.html`) sont eux-mêmes composés de blocs, sérialisés en HTML commenté. Les vérifier avec des tests unitaires classiques a peu de sens : ce qui compte, c'est le rendu final dans un navigateur. Les tests E2E avec `@wordpress/e2e-test-utils`, déjà utilisés pour les blocs personnalisés, s'appliquent ici aussi :

```
import { visitSiteEditor } from '@wordpress/e2e-test-utils';

describe( 'Modèle single du thème', () => {
    it( 'affiche le titre et le contenu de l\'article', async () => {
        await visitSiteEditor( { postId: 'mon-theme//single' } );

        const editeurExiste = await page.$( '.edit-site-visual-editor' );
        expect( editeurExiste ).not.toBeNull();
    } );
} );
```

À ce stade de maturité de l'éditeur de site, les utilitaires dédiés à l'éditeur de site sont encore en évolution rapide d'une version de WordPress à l'autre : il faut s'attendre à devoir ajuster ces tests plus fréquemment qu'avec l'éditeur d'article classique, plus stable.

## Une checklist réaliste pour démarrer

Tester exhaustivement un thème bloc dès aujourd'hui représente un investissement disproportionné compte tenu de la jeunesse de la fonctionnalité. Nous recommandons de concentrer l'effort sur :

- La validation du `theme.json` contre son schéma, en CI, à chaque modification.
- Un test PHPUnit qui vérifie que les réglages critiques (palette, tailles de police) sont bien exposés.
- Des tests E2E sur les cinq modèles les plus visités : accueil, article, page, archive, 404.
- Une vérification visuelle manuelle après chaque mise à jour majeure de WordPress, tant que l'éditeur de site continue d'évoluer aussi vite.

> Sur nos projets de thèmes blocs, nous évitons encore d'investir massivement dans des tests E2E détaillés sur chaque interaction de l'éditeur de site. La surface change trop vite d'une version mineure à l'autre pour que cet investissement soit rentable aujourd'hui ; nous préférons concentrer l'effort sur ce qui casse silencieusement, comme `theme.json`.

## En résumé

La FSE déplace une partie de la logique d'un thème du PHP vers un document JSON structuré et des modèles au format bloc, ce qui déplace aussi la stratégie de test : validation de schéma pour `theme.json`, PHPUnit pour vérifier que les réglages sont bien exposés à l'éditeur, et E2E ciblé sur les modèles les plus critiques. À ce stade de maturité de l'éditeur de site, mieux vaut une couverture ciblée et entretenue qu'une suite exhaustive qui demandera une réécriture à chaque nouvelle version mineure de WordPress.