Un dépôt Git cloné, une documentation minimale, et un dossier tests/ contenant plusieurs dizaines de fichiers : c’est la situation typique d’un développeur qui reprend la maintenance d’un projet WordPress existant. La question se pose immédiatement, avant même de lire une seule ligne de code métier : cette suite de tests mérite-t-elle d’être conservée, ou vaut-il mieux repartir sur des bases plus saines ?
Répondre à cette question à l’instinct, en parcourant rapidement quelques fichiers, mène souvent à une mauvaise décision dans un sens ou dans l’autre : jeter une suite en réalité solide par excès de prudence, ou au contraire s’appuyer sur une suite qui rassure sans réellement protéger contre les régressions. Une grille de lecture structurée en cinq critères permet de trancher plus rapidement et plus objectivement.
Critère 1 : la suite s’exécute-t-elle réellement sans erreur ?
Avant tout jugement sur la qualité, il faut vérifier que la suite de tests hérite s’exécute effectivement, sans erreur de configuration bloquante. Un projet où la commande phpunit échoue immédiatement, faute de base de données de test correctement configurée ou de dépendance manquante, ne dit encore rien sur la qualité des tests eux-mêmes : cette première étape ne fait que rétablir un point de départ observable.
Critère 2 : le ratio entre tests et assertions
Un nombre élevé de méthodes de test ne garantit rien si chacune ne contient qu’une seule assertion superficielle. Il est utile de comparer, sur un échantillon représentatif de fichiers, le nombre de méthodes de test au nombre total d’assertions qu’elles contiennent :
- Une moyenne inférieure à une assertion par test signale souvent des tests qui vérifient un code HTTP 200 sans jamais examiner le contenu réellement retourné.
- Une moyenne autour de trois à cinq assertions par test, bien réparties, indique généralement une vérification plus substantielle du comportement testé.
- Un nombre très élevé d’assertions dans une seule méthode peut au contraire signaler un test qui mélange plusieurs comportements distincts, difficile à diagnostiquer en cas d’échec partiel.
Critère 3 : les tests couvrent-ils les cas limites, ou seulement le chemin heureux ?
Un test qui vérifie uniquement qu’une fonction retourne le bon résultat avec des données parfaitement valides ne protège pas contre les régressions les plus fréquentes en production, généralement provoquées par des données inattendues : une chaîne vide, un identifiant inexistant, un utilisateur sans les permissions requises. Parcourir quelques classes de test à la recherche de méthodes nommées explicitement autour d’un cas limite, ou de l’absence totale de telles méthodes, donne une indication rapide et fiable sur ce point.
Critère 4 : les tests sont-ils indépendants les uns des autres ?
# Une commande simple pour révéler une dépendance à l'ordre d'exécution
phpunit --order-by=random --random-order-seed=1
phpunit --order-by=random --random-order-seed=2
Exécuter la suite héritée deux fois avec des graines d’ordre aléatoire différentes révèle rapidement si des tests dépendent d’un état laissé par d’autres. Une suite qui échoue systématiquement avec l’ordre par défaut mais réussit avec un ordre aléatoire, ou l’inverse, indique un problème d’isolation qu’il faudra corriger avant de faire confiance aux résultats futurs.
Critère 5 : la vitesse d’exécution de la suite complète
Une suite qui prend plusieurs dizaines de minutes à s’exécuter dissuade naturellement les développeurs de la lancer fréquemment, ce qui réduit son utilité réelle au fil du temps, même si sa qualité intrinsèque est correcte. Mesurer ce temps d’exécution dès la reprise du projet permet d’anticiper si un effort de parallélisation ou de séparation entre tests rapides et tests lents sera nécessaire à moyen terme.
| Critère | Signal positif | Signal d’alerte |
|---|---|---|
| Exécution | La suite tourne sans configuration supplémentaire | Erreurs de connexion ou dépendances manquantes dès le départ |
| Assertions | Plusieurs assertions pertinentes par test | Un seul contrôle de code HTTP, sans vérification du contenu |
| Cas limites | Des tests nommés explicitement autour d’erreurs attendues | Uniquement des scénarios de succès |
| Isolation | Résultats identiques quel que soit l’ordre d’exécution | Échecs qui apparaissent selon l’ordre choisi |
| Vitesse | Quelques minutes pour la suite complète | Dizaines de minutes, dissuadant l’exécution fréquente |
Une suite de tests héritée n’est ni bonne ni mauvaise par sa seule taille : elle vaut ce que valent ses assertions, son isolation et sa capacité réelle à détecter une régression avant qu’elle n’atteigne la production.
Que faire selon le résultat de la grille
Une suite qui échoue sur la majorité de ces cinq critères ne mérite généralement pas d’être conservée telle quelle : il est souvent plus rentable de la traiter comme une base à retravailler progressivement, en commençant par les fonctionnalités critiques du projet, plutôt que de chercher à sauver chaque fichier existant. À l’inverse, une suite qui satisfait la majorité de ces critères mérite d’être conservée et étendue, même si quelques ajustements ponctuels restent nécessaires.
En résumé
Reprendre un projet WordPress avec une suite de tests existante ne devrait jamais se solder par un jugement instantané, favorable ou défavorable, formé sur une simple impression de lecture. Ces cinq critères, l’exécution effective, la densité des assertions, la couverture des cas limites, l’isolation entre tests et la vitesse d’exécution, donnent une base objective pour décider en une matinée si cette suite mérite d’être conservée, retravaillée, ou progressivement remplacée.
