PHPUnit 7 face à PHPUnit 9, tous deux capables de faire tourner la même suite de tests grâce à une seule dépendance de compatibilité : c’est ce qu’a permis, sur plusieurs projets suivis, l’adoption de yoast/phpunit-polyfills, sans quoi chaque montée de version de PHPUnit aurait exigé une réécriture partielle des tests existants.
Ce comparatif s’appuie sur des constats faits projet après projet, pas sur une matrice officielle universelle : la version de PHPUnit réellement utilisable dépend autant de la version de WordPress que de celle de PHP installée sur l’environnement, ce qui rend toute règle absolue trompeuse. Ce sujet ne couvre pas PHPUnit 11, traité séparément.
Le tableau constaté sur nos projets
| Génération de WordPress | PHP typiquement installé | PHPUnit utilisé en pratique |
|---|---|---|
| WordPress 5.6 à 5.8 | PHP 7.4 ou 8.0 | PHPUnit 7 à 9 |
| WordPress 5.9 à 6.1 | PHP 8.0 ou 8.1 | PHPUnit 7 à 9 (via polyfills) |
| WordPress 6.2 à 6.4 | PHP 8.1 ou 8.2 | PHPUnit 9, PHPUnit 10 en usage encore minoritaire |
| WordPress 6.5 | PHP 8.2 ou 8.3 | PHPUnit 9 ou 10, selon la dépendance à d’anciens paquets tiers |
Ce qui contraint réellement le choix
Le facteur le plus souvent sous-estimé n’est pas la version de WordPress elle-même, qui reste tolérante sur la version de PHPUnit tant que yoast/phpunit-polyfills est présent, mais les dépendances tierces du projet : un paquet d’analyse statique, un plugin Composer, ou une extension propriétaire encore ancrée sur une ancienne API de PHPUnit peuvent bloquer une montée de version bien après que le cœur de WordPress et PHP l’autorisent techniquement.
Le rôle précis de phpunit-polyfills
Ce paquet ne change pas la version de PHPUnit installée : il fournit une couche d’assertions et de méthodes de cycle de vie qui fonctionnent identiquement, que le projet tourne sous PHPUnit 7, 8 ou 9. Concrètement, une méthode comme expectExceptionMessageMatches(), absente des toutes premières versions de PHPUnit 7, devient disponible via ce pont de compatibilité sans devoir écrire de code conditionnel selon la version installée.
Une méthode simple pour vérifier sa propre marge de manœuvre
- Identifier la version de PHP réellement disponible sur l’environnement de production visé, souvent la contrainte la plus rigide.
- Consulter la contrainte de version PHPUnit exprimée dans le
composer.jsondu projet et de ses dépendances directes. - Lancer la suite existante avec la version de PHPUnit la plus récente compatible avec cette version de PHP, en environnement isolé, avant de modifier quoi que ce soit dans le projet principal.
- Ne remonter la contrainte de version dans le
composer.jsondu projet qu’après ce test préalable réussi.
Un piège fréquent : confondre compatibilité et disponibilité
Une version de PHPUnit peut être techniquement compatible avec une version de PHP donnée tout en restant absente des dépôts figés d’un environnement d’hébergement partagé, ou en conflit avec une contrainte de version fixée par un autre paquet du même projet. Vérifier la compatibilité théorique ne suffit pas : un essai réel d’installation via Composer, dans un environnement représentatif de la production, reste la seule vérification fiable avant d’annoncer une montée de version à une équipe.
Documenter la matrice pour la prochaine montée
Le tableau constaté ci-dessus perd de sa valeur s’il reste dans la mémoire d’une seule personne de l’équipe. Le consigner dans un fichier versionné aux côtés du composer.json, mis à jour à chaque montée de version réellement effectuée plutôt qu’à chaque annonce officielle, évite de redécouvrir les mêmes contraintes à chaque nouvelle génération de WordPress. Cette discipline coûte peu de temps sur le moment et fait gagner, à l’échelle d’un an, plusieurs heures de vérifications redondantes réparties entre plusieurs projets suivis par la même équipe.
En résumé
Le choix d’une version de PHPUnit pour un projet WordPress dépend moins de la version du cœur elle-même que de la version de PHP disponible et des contraintes posées par les dépendances tierces. Le pont yoast/phpunit-polyfills réduit considérablement les frictions entre générations de PHPUnit, mais ne dispense jamais de vérifier concrètement, dans un environnement isolé, qu’une montée de version reste réalisable avant de l’annoncer comme acquise.
