# Comparatif des versions de PHPUnit compatibles WordPress, montée après montée

> Panorama pratique des versions de PHPUnit qui ont cohabité avec chaque génération récente de WordPress, pour planifier une montée de version sans mauvaise surprise.

- Auteur : WordPress Développement
- Publié le : 2024-05-05
- Mis à jour le : 2024-05-05
- Catégorie : Tests
- URL : https://www.wpmoderne.fr/tests/comparatif-versions-phpunit-compatibles-wordpress/

## L’essentiel

- yoast/phpunit-polyfills absorbe l'essentiel des écarts entre versions majeures de PHPUnit
- La version de PHP installée contraint souvent davantage que la version de WordPress elle-même
- Chaque montée de version mérite un test de la suite avant celui du reste du projet

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 |

> L'essentiel à retenir : yoast/phpunit-polyfills absorbe l'essentiel des écarts entre versions majeures de PHPUnit ; La version de PHP installée contraint souvent davantage que la version de WordPress elle-même ; Chaque montée de version mérite un test de la suite avant celui du reste du projet

## 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

1. Identifier la version de PHP réellement disponible sur l'environnement de production visé, souvent la contrainte la plus rigide.
2. Consulter la contrainte de version PHPUnit exprimée dans le `composer.json` du projet et de ses dépendances directes.
3. 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.
4. Ne remonter la contrainte de version dans le `composer.json` du 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.