Valider une montée de version : le rôle exact des tests

Dans une montée de version Symfony, la suite de tests ne sert pas seulement de filet. Elle est aussi l'instrument qui révèle ce qu'il faut corriger. Cette double fonction change la façon de préparer le chantier, et elle explique pourquoi deux applications au même numéro de version ne représentent pas du tout le même travail.

Le pont PHPUnit transforme la suite en détecteur

Premier fait à connaître, et il surprend : par défaut, PHPUnit n'affiche aucun avertissement de dépréciation. Le guide officiel de montée majeure le dit sans détour. Une suite qui passe au vert ne prouve donc rien quant à l'usage de code déprécié, et il est tentant d'en tirer la conclusion inverse.

Le correctif tient en une dépendance de développement, `symfony/phpunit-bridge`. Une fois installé, ce pont affiche à la fin du rapport de tests un récapitulatif de tous les avertissements de dépréciation rencontrés, avec leur nombre d'occurrences et le nom des tests qui les ont déclenchés. La sortie devient une liste de travail : chaque ligne est un endroit à corriger, et la commande se termine par un code de succès une fois qu'il n'en reste plus.

Le guide décrit aussi le régime intermédiaire, celui où l'on ne peut pas tout corriger tout de suite, par exemple parce qu'une dépréciation vient d'un composant qu'on doit encore supporter. La variable d'environnement `SYMFONY_DEPRECATIONS_HELPER` accepte alors un plafond de tolérance, réglable dans la configuration PHPUnit du projet ou passé à la volée. C'est le bon outil pour intégrer la mesure à l'intégration continue sans bloquer les livraisons dès le premier jour : on pose le plafond au niveau actuel, et on le fait descendre.

Conséquence : la couverture détermine la visibilité

Un avertissement de dépréciation se déclenche à l'exécution du code concerné. Un chemin qu'aucun test ne parcourt n'en émettra aucun, ce qui ne signifie pas qu'il est propre : cela signifie qu'il n'a pas été mesuré. La couverture de tests cesse ici d'être un indicateur de qualité pour devenir tout autre chose, la surface de votre détecteur. C'est le raisonnement inverse de celui qu'on tient d'habitude sur la couverture, et c'est celui qui compte pendant une montée.

Le second capteur est le profileur de l'environnement de développement, qui affiche les mêmes avertissements dans la barre d'outils de débogage à chaque page consultée. Il a la même limite, formulée autrement : il ne voit que les pages que quelqu'un a effectivement ouvertes. L'union des deux capteurs, tests automatisés et parcours manuels, constitue tout ce que vous pouvez voir. Le reste est un angle mort qu'il faut assumer comme tel plutôt que le confondre avec une absence de problème.

Et si l'application n'a pas de tests

Cela arrive, et la mauvaise réponse consiste à écrire d'abord la suite de tests qui manque. Vous transformeriez une montée de version en projet de reprise de qualité, deux chantiers dont les critères de réussite n'ont rien à voir, et vous n'auriez toujours pas monté de version au bout de six mois.

La réponse utile est plus étroite : écrire le minimum de tests qui couvre ce qui ne doit surtout pas casser. Les parcours où circule de l'argent, ceux qui ont des conséquences juridiques, ceux qui écrivent dans la base. Pas de tests unitaires fins sur les classes, mais des tests de bout en bout qui figent le comportement observable actuel, celui qui est en production et que personne ne discute. Ils n'ont pas besoin d'être élégants ni durables : ils servent pendant le chantier et vous déciderez de leur sort après.

Complétez par un parcours manuel scripté des mêmes chemins dans l'environnement de développement, profileur ouvert, avant et après chaque palier. C'est rudimentaire, c'est efficace, et cela donne une trace comparable d'une étape à l'autre. L'objectif n'est pas d'acheter de la qualité, il est d'acheter de la visibilité pour la durée du chantier.

Ce que les tests ne verront pas

• Les ruptures qui ne passent pas par une dépréciation : une majeure a le droit de casser la compatibilité, et le fichier UPGRADE de la version visée est le seul endroit où ces changements sont listés.
• Les fichiers de configuration et les gabarits, qui ne s'exécutent pas dans la plupart des suites de tests et n'émettent donc rien.
• Les avertissements produits par une bibliothèque tierce plutôt que par votre code : le guide officiel recommande de mettre à jour la bibliothèque en question, ces dépréciations étant souvent déjà traitées en amont.
• Les régressions de performance, qui ne font échouer aucun test tant qu'aucun seuil n'est mesuré.

Questions fréquentes