Six fois plus rapide. C’est l’écart mesuré entre une suite Vitest et son équivalent en Playwright Component Testing, sur le même jeu de vingt composants de blocs Gutenberg développés pour plusieurs clients d’agence. Mais la rapidité n’est pas le seul critère qui compte quand on teste un bloc dont le rendu dépend fortement du CSS et du comportement réel du navigateur.
Ce comparatif s’appuie sur un projet concret : une agence qui maintient une bibliothèque de blocs partagée entre plusieurs sites clients, avec des besoins de test qui vont du simple rendu conditionnel à des interactions complexes (glisser-déposer dans l’éditeur, redimensionnement). Jest n’entre pas dans ce comparatif, déjà mis face à Vitest dans un autre article, à propos d’un contexte différent.
Ce que teste réellement Vitest sur un composant de bloc
Vitest, couplé à @testing-library/react, exécute les composants dans un DOM simulé par jsdom ou happy-dom. C’est rapide — pas de navigateur à démarrer — mais le rendu final, notamment les propriétés calculées par le CSS (largeurs réelles, débordements, media queries), n’est jamais évalué. Un test Vitest vérifie que le bon texte, les bons attributs ARIA et la bonne structure DOM sont présents, pas que le composant s’affiche correctement à l’écran.
Ce que change Playwright Component Testing
Playwright Component Testing monte le composant dans un vrai navigateur (Chromium, Firefox ou WebKit), avec le CSS réellement appliqué. Pour un bloc dont le comportement dépend de la taille du conteneur (un bloc de galerie qui réorganise ses colonnes selon la largeur disponible), c’est la seule méthode qui vérifie fidèlement le résultat visuel, sans simulation.
Comparatif sur les critères qui comptent en agence
| Critère | Vitest | Playwright Component Testing |
|---|---|---|
| Vitesse d’exécution (20 composants) | ~4 secondes | ~24 secondes |
| Fidélité du rendu CSS | Simulée, non fiable | Réelle, fiable |
| Interactions complexes (drag and drop) | Difficile à simuler correctement | Nativement supporté |
| Intégration à une CI existante Jest/Vitest | Immédiate | Nécessite une configuration séparée |
| Debug visuel (captures d’écran d’échec) | Non disponible | Disponible nativement |
Notre règle de répartition sur ce projet
- Les blocs purement logiques (affichage conditionnel selon les attributs, formatage de texte) restent testés en Vitest, pour la vitesse d’itération pendant le développement
- Les blocs dont le rendu dépend du CSS ou de la taille du conteneur (galerie, grille responsive, colonnes) passent en Playwright Component Testing
- Les blocs avec interaction complexe dans l’éditeur (redimensionnement à la souris, glisser-déposer entre colonnes) sont exclusivement testés en Playwright
Sur les vingt composants du projet, cette répartition a donné quatorze tests Vitest et six tests Playwright Component Testing — un ratio qui reflète la proportion réelle de logique pure contre rendu visuel dans cette bibliothèque de blocs.
Un point souvent négligé : la maintenance des deux outillages
Faire cohabiter deux frameworks de test dans un même projet a un coût d’entretien réel : deux configurations, deux jeux de mocks, deux façons d’écrire les assertions. Ce coût doit être mis en balance avec le gain de fidélité obtenu, en particulier pour une agence qui doit former plusieurs développeurs aux mêmes outils.
Le bon outil de test n’est jamais celui qui gagne en benchmark, mais celui qui vérifie la chose qui casse vraiment en production.
Notre verdict
Ni Vitest ni Playwright Component Testing ne l’emporte dans l’absolu : le choix dépend de la nature du bloc testé. Une bibliothèque de blocs d’agence, avec des besoins hétérogènes, gagne à faire cohabiter les deux plutôt qu’à en imposer un seul par dogmatisme.
