Sur un projet de dix-huit blocs personnalisés pour un client du secteur de l’assurance, notre suite de tests unitaires JavaScript avait fini par dépasser vingt secondes d’exécution complète, un chiffre qui paraît anodin isolément mais qui, multiplié par les dizaines d’exécutions quotidiennes d’un développeur en watch mode, use la patience. Nous avons profité d’un cycle de maintenance pour migrer cette suite de Jest vers Vitest et mesurer objectivement ce que ce changement apportait, au-delà de l’effet de mode.
Ce comparatif se concentre volontairement sur les tests unitaires de logique de blocs — fonctions de transformation d’attributs, composants d’édition testés avec la bibliothèque de test React — et laisse de côté les tests end-to-end, qui relèvent d’un outillage différent.
Vitesse d’exécution : l’écart le plus visible
Sur notre suite de 86 tests répartis en 24 fichiers, Jest s’exécutait en 21,3 secondes en mode complet, contre 6,2 secondes pour Vitest, soit un gain d’un facteur 3,4. L’essentiel de cet écart vient de la transformation à la volée par esbuild côté Vitest, contre la transformation Babel plus lente utilisée par défaut avec Jest. En mode watch, l’écart est encore plus perceptible : Vitest ne relance que les fichiers impactés par un changement, avec un retour en dessous de la seconde sur la majorité des modifications.
Configuration : le confort de @wordpress/scripts a un prix
@wordpress/scripts fournit une commande wp-scripts test-unit-js préconfigurée autour de Jest, avec les transformations nécessaires pour JSX, les alias vers les paquets @wordpress/*, et une configuration de mocks pour les appels à l’API REST. Basculer vers Vitest signifie renoncer à cette configuration prête à l’emploi et réécrire soi-même les équivalents :
// vitest.config.js
import { defineConfig } from 'vitest/config';
import react from '@vitejs/plugin-react';
export default defineConfig({
plugins: [react()],
test: {
environment: 'jsdom',
globals: true,
setupFiles: ['./test/setup-vitest.js'],
},
resolve: {
alias: {
'@wordpress/blocks': '@wordpress/blocks/build-module',
'@wordpress/i18n': '@wordpress/i18n/build-module',
},
},
});Cette réécriture a représenté environ une demi-journée de travail sur notre projet, principalement passée à retrouver les bons chemins de résolution des paquets @wordpress/*, qui ne publient pas systématiquement une version ESM directement consommable par Vite.
Tableau comparatif sur les critères qui comptent en agence
| Critère | Jest (via @wordpress/scripts) | Vitest |
|---|---|---|
| Vitesse suite complète (86 tests) | 21,3 s | 6,2 s |
| Configuration initiale | Prête à l’emploi | À écrire à la main |
| Compatibilité paquets @wordpress/* | Native | Alias manuels nécessaires |
| Mode watch | Correct | Très réactif (HMR-like) |
| Snapshots de composants | Mature, largement documenté | Compatible, écosystème plus jeune |
| Maintenance de la config au fil des mises à jour WP | Prise en charge par l’équipe cœur | À la charge du projet |
Le cas des snapshots de rendu de bloc
Les tests de snapshot, utiles pour détecter un changement inattendu de rendu HTML d’un bloc, fonctionnent avec les deux outils, mais le format de sortie diffère légèrement, ce qui invalide tous les snapshots existants lors d’une migration. Sur notre projet, cela a représenté la régénération de 34 fichiers de snapshot, un exercice mécanique mais qu’il faut budgétiser avant de se lancer.
Notre verdict
Pour un projet neuf ou de taille modeste, rester sur @wordpress/scripts et Jest reste le choix le plus rationnel : la configuration est fournie, maintenue par l’équipe cœur, et le gain de vitesse ne se fait sentir qu’à partir d’un certain volume de tests. Pour un projet mature avec plusieurs dizaines de blocs et une équipe qui lance les tests en continu pendant le développement, le gain de réactivité de Vitest justifie l’investissement de configuration, à condition d’accepter de maintenir soi-même les alias vers les paquets WordPress. Nous avons fait la bascule sur trois projets à ce jour, jamais sur un projet de moins de dix blocs.
