# Pourquoi WP_UnitTestCase hérite encore de TestCase après dix ans de suite

> Retour sur un choix d'architecture jamais remis en cause dans le cœur de WordPress : pourquoi la classe de base des tests reste construite au-dessus de PHPUnit plutôt qu'à côté.

- Auteur : WordPress Développement
- Publié le : 2023-08-21
- Mis à jour le : 2023-08-21
- Catégorie : Tests
- URL : https://www.wpmoderne.fr/tests/pourquoi-wp-unittestcase-herite-testcase-dix-ans/

## L’essentiel

- WP_UnitTestCase hérite de la classe de test de PHPUnit plutôt que de la réimplémenter
- Ce choix permet de profiter directement des assertions et du cycle de vie de PHPUnit
- Le pont phpunit-polyfills a été ajouté plus tard pour absorber les changements de version de PHPUnit

« WP_UnitTestCase extends WP_UnitTestCase_Base » — cette ligne, présente dans le code source du cœur de WordPress, résume à elle seule un choix d'architecture qui n'a jamais été remis en question depuis l'adoption de PHPUnit par le projet : construire la classe de test propre à WordPress par héritage direct de l'infrastructure de PHPUnit, plutôt que d'écrire un framework de test maison.

Dix ans plus tard, ce choix continue de structurer toute suite de tests d'intégration WordPress. Comprendre pourquoi il a été fait, et pourquoi il tient toujours, aide à mieux situer ce que `WP_UnitTestCase` apporte réellement par-dessus PHPUnit.

## Le problème initial : tester du code fortement procédural

Le cœur de WordPress s'appuie massivement sur des fonctions globales, des variables superglobales et un système de hooks. Ce style rendait délicat l'écriture de tests unitaires classiques, qui supposent généralement d'isoler une unité de code de ses dépendances. La réponse retenue n'a pas été de réécrire le cœur pour le rendre plus « testable » au sens strict, mais de construire une classe de test qui prend en charge, à chaque test, la remise à zéro de cet état global : base de données rechargée dans une transaction annulée en fin de test, hooks réinitialisés, options remises à leur valeur par défaut.

Cette responsabilité de remise à zéro est déléguée aux méthodes `setUp()` et `tearDown()` héritées de PHPUnit, complétées par la surcouche WordPress. Réinventer un cycle de vie de test parallèle à celui de PHPUnit aurait dupliqué une mécanique déjà éprouvée, pour un bénéfice incertain.

## Le bénéfice concret de l'héritage direct

En héritant directement de la classe de test de PHPUnit, `WP_UnitTestCase` donne accès, sans aucune couche de traduction, à l'ensemble des assertions du framework (`assertSame`, `assertCount`, `expectException`), à son système de fournisseurs de données, et à ses extensions tierces (comme les doublures de test). Un développeur qui maîtrise PHPUnit sur un projet applicatif classique retrouve immédiatement ses repères sur un projet WordPress, sans apprendre un vocabulaire d'assertions différent.

> L'essentiel à retenir : WP_UnitTestCase hérite de la classe de test de PHPUnit plutôt que de la réimplémenter ; Ce choix permet de profiter directement des assertions et du cycle de vie de PHPUnit ; Le pont phpunit-polyfills a été ajouté plus tard pour absorber les changements de version de PHPUnit

## La tension apparue avec les montées de version de PHPUnit

Ce choix d'héritage direct a un revers : chaque montée de version majeure de PHPUnit modifie parfois la classe dont `WP_UnitTestCase` hérite, ou le comportement de certaines méthodes internes. Pendant plusieurs années, cela a contraint des projets à figer une version ancienne de PHPUnit pour rester compatibles avec la suite de tests du cœur, un compromis inconfortable pour des équipes qui souhaitaient par ailleurs profiter des nouveautés des versions récentes du framework.

La réponse apportée n'a pas consisté à abandonner l'héritage direct, mais à introduire une couche de compatibilité intermédiaire, le paquet `yoast/phpunit-polyfills`, qui absorbe les différences d'API entre les versions successives de PHPUnit. Le principe architectural d'origine — hériter plutôt que réimplémenter — est resté intact ; seule la façon d'amortir les changements de version a évolué.

## Ce que cette architecture n'a jamais cherché à résoudre

- Elle ne rend pas le code du cœur plus testable de façon isolée : elle contourne le problème en réinitialisant l'état global à chaque test, plutôt que de réduire les dépendances à cet état.
- Elle ne remplace pas un besoin de tests unitaires purs pour la logique métier d'une extension, qui gagne à être écrite indépendamment de cette classe de base, comme le montrent les approches qui isolent la logique dans des fonctions pures.
- Elle n'a jamais visé la rapidité d'exécution : chaque test repose sur une transaction de base de données, ce qui a un coût, assumé au profit de la fidélité du comportement testé.

## Pourquoi ce choix n'a jamais été reconsidéré

Changer l'architecture de base des tests du cœur impliquerait de réécrire des milliers de tests existants, à la fois dans le cœur de WordPress et dans l'écosystème des extensions et thèmes qui étendent `WP_UnitTestCase`. Le coût d'une telle migration dépasserait largement le bénéfice attendu, alors que la couche de compatibilité ajoutée a déjà résolu le principal point de friction, celui des montées de version de PHPUnit.

## En résumé

L'héritage direct de `WP_UnitTestCase` depuis la classe de test de PHPUnit reflète un arbitrage pragmatique pris tôt dans l'histoire du projet : profiter d'un framework de test déjà mature plutôt que d'en écrire un nouveau pour un code historiquement procédural. Ce choix a survécu dix ans grâce à l'ajout d'une couche de compatibilité qui absorbe les évolutions de PHPUnit sans jamais toucher au principe d'origine.