Deprecated: Implicit conversion from float to int loses precision. Ce message s’affiche depuis des semaines dans les journaux d’exécution de la suite de tests, noyé parmi des centaines de lignes similaires, sans jamais faire échouer un seul test. Puis vient le jour où l’équipe met enfin à jour sa version de PHPUnit, restée figée depuis longtemps par prudence, et une trentaine de tests échouent d’un coup, sans qu’aucune ligne de code métier n’ait changé entretemps.
Ce scénario est plus courant qu’il n’y paraît. Une dépréciation, par définition, n’interrompt rien immédiatement : elle prévient qu’un comportement sera retiré ou modifié dans une version future, tout en continuant à fonctionner dans la version actuelle. C’est précisément cette tolérance temporaire qui permet à la dette de s’accumuler sans être visible dans les résultats de test au jour le jour.
Comment le signal se perd dans le bruit
Une suite de tests volumineuse produit naturellement beaucoup de sortie console. Quand chaque exécution affiche déjà des centaines de lignes d’information, d’avertissement ou de log applicatif, une nouvelle ligne de dépréciation se fond dans cette masse. Personne ne la remarque activement, parce que le résultat final reste identique : tous les tests passent, la barre verte s’affiche, et l’attention se porte ailleurs.
- La dépréciation n’apparaît dans aucun résumé synthétique en fin d’exécution, sauf configuration spécifique.
- Elle est souvent émise par du code tiers, une extension ou une bibliothèque, plutôt que par le code du projet lui-même, ce qui donne l’impression qu’elle « ne concerne pas » l’équipe.
- Elle se répète à l’identique à chaque exécution, ce qui la rend familière au point de devenir invisible, un peu comme un bruit de fond constant qu’on cesse d’entendre.
Le jour où tout devient visible
Une montée de version de PHPUnit transforme souvent une dépréciation tolérée en comportement réellement modifié ou en erreur stricte. Une méthode d’assertion qui acceptait auparavant un argument d’un type imprécis peut désormais exiger un type strict. Un comportement implicite, comme une conversion automatique entre types numériques, peut devenir une erreur bloquante plutôt qu’un simple avertissement.
À ce moment précis, tous les endroits où cette dépréciation avait été ignorée échouent simultanément, souvent avec des messages qui ne pointent plus vers la dépréciation d’origine mais vers sa conséquence directe : un test qui échoue sur une assertion qui semblait pourtant correcte à l’écriture, des mois auparavant.
Un exemple concret
public function test_calcule_le_nombre_de_pages(): void {
$total_articles = 47;
$par_page = 10;
// Division qui produit un flottant, assigné implicitement à une variable
// ensuite utilisée là où un entier strict est attendu
$nombre_pages = $total_articles / $par_page;
$this->assertEquals( 5, $nombre_pages );
}
Ce test passait sans avertissement visible pendant longtemps, la conversion implicite entre flottant et entier étant tolérée silencieusement. Une évolution du comportement interne des assertions numériques peut rendre cette même comparaison plus stricte, révélant que 4.7 n’est jamais réellement égal à 5, ce que l’assertion précédente masquait par une conversion implicite.
La correctif : traiter chaque dépréciation dès son apparition
La solution ne consiste pas à attendre la montée de version pour découvrir le problème, mais à surveiller activement les dépréciations dès leur première apparition dans les journaux d’exécution. Plusieurs pratiques rendent ce suivi réaliste sur la durée :
- Configurer PHPUnit pour afficher un résumé distinct des dépréciations en fin d’exécution, plutôt que de les laisser noyées dans le flux général.
- Traiter l’apparition d’une nouvelle dépréciation comme un ticket à part entière, même mineur, plutôt que comme un simple bruit à ignorer.
- Planifier des montées de version régulières et rapprochées de PHPUnit, plutôt que des sauts espacés de plusieurs années qui accumulent un volume de changements difficile à absorber d’un coup.
Une dépréciation ignorée ne disparaît jamais : elle attend simplement la prochaine montée de version pour se manifester, au pire moment possible, sous la forme d’une dizaine d’échecs simultanés sans lien apparent entre eux.
Pourquoi les petites montées de version aident
Une équipe qui reste bloquée sur une ancienne version de PHPUnit pendant plusieurs années, par crainte de casser sa suite de tests, obtient l’effet inverse de celui recherché : elle transforme une série de petits ajustements progressifs en une seule migration massive et risquée. Monter de version régulièrement, dès qu’une nouvelle version stable paraît, répartit l’effort d’adaptation dans le temps et garde chaque changement suffisamment petit pour être compris rapidement.
En résumé
Une dépréciation silencieuse dans une suite de tests n’est jamais un problème définitivement réglé simplement parce qu’aucun test n’échoue aujourd’hui. Elle représente une dette qui se révèle intégralement au moment le moins choisi, généralement lors d’une montée de version repoussée trop longtemps. Traiter chaque avertissement dès son apparition, plutôt que de le tolérer indéfiniment, évite cette accumulation et rend chaque montée de version future beaucoup plus prévisible.
