« Deprecated: Implicitly marking parameter as nullable is deprecated » : ce message, familier depuis PHP 8.4, sorti en novembre 2024, apparaît surtout dans les discussions autour du code applicatif. Il se cache pourtant tout autant dans le code de test lui-même, en particulier dans les classes de mocks et de stubs écrites à la main, souvent plus anciennes et moins révisées que le code métier qu’elles simulent.
Le cas retenu ici concerne une équipe qui préparait la montée vers PHP 8.4 d’un projet de gestion de dossiers d’inscription scolaire, et qui a découvert que quatorze appels dépréciés se trouvaient non pas dans le code applicatif, déjà audité, mais dans les classes de doublures de test, jamais concernées par les revues précédentes.
Pourquoi le code de test échappe souvent à l’audit
Les campagnes de préparation à une nouvelle version de PHP ciblent en priorité le code qui s’exécute en production, laissant de côté le code de test au motif qu’il ne tourne jamais sur un environnement client. Ce raisonnement néglige un point : le code de test doit lui aussi s’exécuter sous la nouvelle version de PHP en CI, et un avertissement de dépréciation qui s’y déclenche peut, selon la configuration, faire échouer la suite ou simplement disparaître dans le bruit des journaux.
Rendre les dépréciations visibles plutôt que silencieuses
Par défaut, PHPUnit n’échoue pas sur un simple avertissement de dépréciation PHP, il se contente de le journaliser. Configurer PHPUnit pour traiter ces avertissements comme des échecs révèle immédiatement les occurrences cachées :
<!-- phpunit.xml.dist -->
<phpunit>
<php>
<ini name="error_reporting" value="-1"/>
</php>
<source>
<include>
<directory>src</directory>
<directory>tests</directory>
</include>
</source>
</phpunit>
Une fois cette configuration en place et la suite exécutée sous PHP 8.4, les quatorze occurrences dépréciées sont apparues dans le rapport, majoritairement liées à des paramètres implicitement nullables dans les signatures de méthodes de classes de stub écrites plusieurs années auparavant.
Le cas typique rencontré dans les doublures
Une classe de stub simulant un service d’envoi de convocations utilisait une signature du type function envoyer(string $destinataire, DateTime $date = null), valide sans avertissement jusqu’à PHP 8.3, mais désormais signalée par PHP 8.4 puisque le type nullable implicite doit être déclaré explicitement :
// Avant (déprécié en PHP 8.4)
public function envoyer(string $destinataire, DateTime $date = null): bool
// Après (type nullable explicite)
public function envoyer(string $destinataire, ?DateTime $date = null): bool
Une correction systématique, pas ponctuelle
Corriger une occurrence isolée sans chercher les autres aurait laissé passer les treize occurrences restantes. La correction a suivi une recherche systématique dans l’ensemble du dossier tests/, ciblant chaque signature de méthode comportant une valeur par défaut null sans type nullable explicite associé.
- Rechercher chaque occurrence de
= nulldans une signature de méthode du dossier de test, pas uniquement du dossier applicatif. - Vérifier chaque cas trouvé avant correction automatique, certains types nullables implicites restant valides selon le contexte exact.
- Relancer la suite complète sous PHP 8.4 en mode strict après chaque lot de corrections, pour confirmer la disparition des avertissements.
Un avertissement de dépréciation dans le code de test annonce le même problème que dans le code applicatif, seulement avec un public plus restreint pour le remarquer.
En résumé
Préparer une montée vers PHP 8.4 sans auditer le code de test lui-même laisse échapper une part significative des appels dépréciés, en particulier dans les classes de doublures anciennes. Sur ce projet, activer le mode strict de rapport d’erreurs dans la configuration PHPUnit a suffi à révéler quatorze occurrences invisibles jusque-là, toutes corrigées avant la montée de version réelle sur l’environnement de production.
