Couverture de code par les tests en PHP : métriques, outils et astuces

Paradoxe du testeur : 100 % de couverture n'est pas une panacée

Les développeurs se divisent en deux camps : ceux qui écrivent des tests « pour la forme » et ceux qui courent après les 100 % de couverture de code tant convoités. La vérité, comme toujours, se trouve au milieu. Dans cet article, nous allons voir ce qu'est la couverture de code par les tests en PHP, quelles métriques sont vraiment importantes et lesquelles peuvent induire en erreur. Vous apprendrez comment, avec PHPUnit, Xdebug et Infection, transformer les tests d'une routine en un puissant outil de contrôle qualité.

Mettons-nous d'accord tout de suite : cet article ne porte pas sur « comment écrire un test », mais sur comment comprendre que vos tests fonctionnent. Nous parlerons le langage des chiffres, des métriques et des exemples concrets. Si vous codez en PHP et souhaitez que votre code ne s'effondre pas à la première modification, vous êtes au bon endroit.

Qu'est-ce que la couverture de code (Code Coverage) réellement ?

La couverture de code est une métrique qui indique le pourcentage du code source exécuté lors de l'exécution des tests. Cela semble simple, mais derrière ce chiffre se cachent différents niveaux d'analyse :

\n
• Couverture de lignes (Line Coverage) — la métrique la plus basique. Combien de lignes de code sont « touchées » par les tests.
\n
• Couverture de branches (Branch Coverage) — vérifie si toutes les branches possibles des conditions (if/else, switch) ont été exécutées.
\n
• Couverture de chemins (Path Coverage) — la métrique la plus complexe. Vérifie tous les chemins d'exécution possibles du code.
\n
• Couverture de fonctions/méthodes — combien de fonctions ont été appelées au moins une fois.
\n

Pour un développeur PHP, la référence est la couverture de lignes + branches. Mais rappelez-vous : 80 % de couverture de lignes peuvent cacher 40 % de branches non testées. Le code peut être « exécuté », mais la logique peut ne pas être testée.

Pourquoi 100 % de couverture est un piège ?

Imaginez une fonction qui traite les paiements :

<?php\n\nfunction processPayment(float $amount, string $currency): bool {\n    if ($amount <= 0) {\n        throw new InvalidArgumentException('Le montant doit être positif');\n    }\n    \n    $rate = getRate($currency); // API externe\n    $converted = $amount * $rate;\n    \n    if ($converted > 10000) {\n        return false; // confirmation requise\n    }\n    \n    return saveTransaction($converted); // écriture en BDD\n}\n

Un test qui ne vérifie que le scénario réussi (montant > 0, devise USD, conversion < 10000) vous donnera 100 % de couverture de lignes. Mais il ne vérifiera ni l'exception, ni le cas d'un paiement important. Conclusion : le nombre de lignes couvertes n'est pas égal à la qualité des tests.

Outils pour mesurer la couverture en PHP

L'écosystème PHP propose plusieurs outils puissants. Examinons les trois principaux : Xdebug, PCOV et PHPUnit avec son support intégré de la couverture.

Xdebug : un vétéran aux capacités étendues

Xdebug est le débogueur et profileur le plus populaire pour PHP. Il peut collecter des données sur la couverture de code. L'installation est standard :

# Installation via pecl\npecl install xdebug\n\n# Ou via Docker\nRUN pecl install xdebug && docker-php-ext-enable xdebug\n

Dans php.ini, il faut activer le mode de couverture :

xdebug.mode=coverage\n

Lancement avec PHPUnit :

./vendor/bin/phpunit --coverage-html ./reports/coverage\n

Avantages de Xdebug : précision, support des branches, intégration avec CI/CD. Inconvénients : ralentit l'exécution des tests de 3 à 5 fois. Pour les grands projets, cela peut être critique.

PCOV : rapide et léger

PCOV (PHP Code Coverage) est une alternative à Xdebug, créée spécialement pour collecter la couverture. Il ne ralentit pas l'exécution car il ne contient pas de débogueur.

pecl install pcov\n\n# Activation dans php.ini\nextension=pcov.so\npcov.enabled=1\n

Lance