La documentation de la bibliothèque Testing Library résume une idée devenue influente dans l’écosystème JavaScript : écrire des tests, pas trop, surtout des tests d’intégration. Cette formule, associée au modèle du « testing trophy », renverse discrètement la hiérarchie de la pyramide de tests classique, qui plaçait le test unitaire à la base et le plus grand volume.
Pour une équipe qui applique une répartition de tests sans jamais l’avoir vraiment questionnée, ce modèle mérite d’être confronté à la réalité d’un projet WordPress, où une bonne partie du comportement observable dépend justement de l’intégration avec le cœur. Ce billet ne traite pas d’un outil en particulier ; il compare les deux modèles de répartition.
La pyramide classique : beaucoup d’unitaire, peu de bout en bout
Le modèle traditionnel de la pyramide de tests recommande une base large de tests unitaires rapides et isolés, une couche intermédiaire de tests d’intégration plus réduite, et un sommet étroit de tests de bout en bout, lents et coûteux à maintenir. La logique sous-jacente : plus un test est rapide et isolé, plus on peut en écrire, donc plus il doit représenter le socle de la couverture.
Le testing trophy : l’intégration au centre, pas à la marge
Le testing trophy, popularisé par Kent C. Dodds, redistribue ce poids : les tests d’intégration deviennent la catégorie la plus représentée, devant les tests unitaires, avec en plus une base de tests statiques (analyse statique, linting) que la pyramide classique ne mentionnait pas explicitement.
Testing trophy (de haut en bas, par volume croissant)
E2E — peu nombreux, parcours critiques uniquement
Intégration — la couche la plus représentée
Unitaire — présent mais pas majoritaire
Statique — analyse statique, linting, base du trophée
L’argument central : un test unitaire isolé peut passer alors que l’assemblage réel des pièces échoue, parce qu’il ne vérifie qu’une fonction en dehors de son contexte d’exécution véritable. Un test d’intégration, lui, vérifie que les pièces fonctionnent ensemble, ce qui se rapproche davantage de ce qu’un utilisateur final expérimente réellement.
Pourquoi ce modèle parle particulièrement à WordPress
Sur un projet WordPress, une part importante du comportement observable dépend d’une intégration réelle avec le cœur : hooks, requêtes WP_Query, capacités et rôles, système de métadonnées. Un test unitaire isolé qui simule entièrement ces mécanismes via des doublures peut passer alors que la véritable interaction avec WordPress échouerait, par exemple à cause d’un ordre d’exécution de hooks mal anticipé.
WP_UnitTestCase, qui charge un cœur WordPress réel connecté à une base de données de test, correspond précisément à cette couche d’intégration mise en avant par le testing trophy. Une équipe qui a longtemps privilégié des tests unitaires purs, avec Brain Monkey ou WP_Mock, gagne souvent à rééquilibrer sa suite vers davantage de tests WP_UnitTestCase.
Tableau comparatif des deux modèles
| Aspect | Pyramide classique | Testing trophy |
|---|---|---|
| Catégorie majoritaire | Tests unitaires | Tests d’intégration |
| Vitesse d’exécution globale | Très rapide | Modérée, à cause du poids de l’intégration |
| Fidélité au comportement réel | Plus faible sur du code fortement intégré | Plus élevée sur ce même code |
| Adapté à WordPress | Limité sur les hooks et requêtes natives | Bien adapté grâce à WP_UnitTestCase |
Ce que le testing trophy ne change pas
Le bout en bout reste, dans les deux modèles, la catégorie la plus coûteuse à écrire et à maintenir, et reste donc réservée aux parcours véritablement critiques : tunnel de commande, formulaire de contact, authentification. Ce n’est pas parce que l’intégration prend plus de place que le bout en bout doit être abandonné ; il garde une valeur irremplaçable sur ce qu’aucun autre niveau ne peut vérifier, l’expérience réelle dans un navigateur.
Un test qui simule trop parfaitement WordPress finit par tester le simulateur, pas WordPress lui-même : c’est l’angle mort que le testing trophy cherche justement à réduire.
En résumé
Le testing trophy ne remplace pas la pyramide classique par une recette universelle, mais il propose un rééquilibrage utile pour un projet fortement dépendant de son intégration avec un cœur applicatif, ce qui est précisément le cas de WordPress. Réévaluer la part de tests d’intégration face aux tests unitaires purs, sans renoncer à un socle statique et à un sommet de bout en bout ciblé, permet une couverture plus fidèle au comportement réellement observé par un utilisateur.
