Sur une extension e-commerce d’environ 8 000 lignes, la génération d’un rapport de couverture avec Xdebug activé faisait passer la suite de tests de 40 secondes à plus de 4 minutes. De quoi décourager n’importe qui de lancer la couverture régulièrement, alors que c’est justement en la consultant souvent qu’elle devient utile pour repérer les zones de code jamais exercées par un test.
PCOV a été créé précisément pour ce problème : une extension PHP dédiée à la seule mesure de couverture, sans les fonctionnalités de débogage pas à pas d’Xdebug. Le choix entre les deux dépend de ce que vous faites au quotidien avec l’extension installée.
PCOV contre Xdebug : que choisir
Xdebug reste indispensable pour déboguer pas à pas dans un IDE, mais son mode de couverture instrumente chaque ligne exécutée avec un coût de performance important. PCOV, lui, ne fait qu’une seule chose : compter les lignes couvertes, avec un impact minime sur la vitesse d’exécution. Si votre poste sert principalement à déboguer, gardez Xdebug installé mais désactivez son mode couverture par défaut ; si vous voulez juste un rapport de couverture rapide et régulier, PCOV est le bon choix.
# Installer PCOV via PECL
pecl install pcov
echo "extension=pcov.so" >> php.ini
# Ou avec Xdebug déjà présent, forcer le mode couverture uniquement
export XDEBUG_MODE=coverage
Configurer PHPUnit pour générer le rapport
La configuration se fait dans phpunit.xml, en délimitant précisément le périmètre à couvrir pour éviter d’inclure les dépendances tierces dans le calcul :
<coverage>
<include>
<directory suffix=".php">src</directory>
</include>
<exclude>
<directory>src/vendor</directory>
</exclude>
<report>
<html outputDirectory="tests/_output/coverage"/>
<text outputFile="php://stdout" showUncoveredFiles="true"/>
</report>
</coverage>
La commande vendor/bin/phpunit --coverage-html tests/_output/coverage génère un rapport navigable, avec chaque fichier PHP coloré ligne par ligne : vert pour couvert, rouge pour jamais exécuté, gris pour non exécutable (commentaires, accolades).
Lire le rapport sans se tromper de priorité
Le pourcentage global affiché en page d’accueil du rapport est la donnée la moins utile. Ce qui compte vraiment se trouve dans le détail fichier par fichier :
- Repérer les fichiers à 0 % de couverture avant de s’attarder sur ceux déjà à 80 %
- Regarder en priorité les branches conditionnelles (
if/else) jamais couvertes des deux côtés - Se méfier des lignes rouges dans le code de gestion d’erreur : c’est souvent le chemin le moins testé et le plus critique en production
Le piège du 100 % qui rassure à tort
Une ligne exécutée par un test n’est pas une ligne vérifiée par une assertion pertinente. Un test qui appelle une fonction sans jamais faire d’assertEquals() sur son résultat fait grimper la couverture à 100 % tout en ne détectant aucune régression.
Sur nos projets, la couverture sert de carte pour repérer les zones mortes, jamais d’objectif chiffré à atteindre pour lui-même. Un module à 60 % avec de bonnes assertions sur les cas limites vaut mieux qu’un module à 100 % rempli d’appels sans vérification.
En résumé
PCOV pour un usage courant et rapide, Xdebug quand vous avez déjà besoin de son mode débogage : le choix n’a rien d’idéologique, il dépend de votre flux de travail. Le pourcentage de couverture reste un indicateur de zones non testées, pas un objectif en soi — la politique de couverture minimale à imposer à une équipe est une décision distincte, qui dépasse la seule configuration technique.
