Code coverage

La couverture de code, ou code coverage, est le pourcentage du code source réellement exécuté pendant que la suite de tests automatisés tourne. Elle mesure ce que les tests traversent, et non ce qu'ils vérifient.

Cette nuance fait toute la difficulté du sujet. Un test qui appelle une fonction sans rien contrôler de son résultat fait monter la couverture exactement comme un test rigoureux. L'indicateur signale où le filet est absent ; il ne dit jamais si le filet en place est solide.

Ce que l'on mesure exactement

Plusieurs granularités coexistent, et le chiffre annoncé change selon celle qui est retenue.

• La couverture de lignes : la part des lignes exécutées au moins une fois.
• La couverture de branches : la part des chemins conditionnels empruntés. Une condition testée uniquement dans le cas favorable affiche cent pour cent de lignes et cinquante pour cent de branches.
• La couverture de fonctions : la part des fonctions appelées au moins une fois.

C'est la couverture de branches qui renseigne le mieux, parce que les défauts se logent presque toujours dans le chemin que personne n'a essayé. Les outils de mesure sont intégrés aux principaux environnements de test, et une plateforme d'analyse de qualité permet d'en suivre l'évolution dans le temps.

À quoi cela sert concrètement

• Repérer les zones du code qu'aucun test ne touche, en particulier après une reprise de projet.
• Poser un garde-fou en intégration continue, pour empêcher qu'une modification arrive sans test.
• Évaluer le risque avant une refonte, car réécrire un module sans couverture coûte toujours plus cher que prévu.
• Objectiver un audit technique, en distinguant ce qui est protégé de ce qui ne l'est pas.

Les pièges de l'objectif chiffré

Dès qu'un pourcentage devient une cible contractuelle, il cesse d'être une mesure. Apparaissent alors les tests sans assertion, écrits pour faire monter le chiffre, et les tests d'accesseurs triviaux pendant que la logique métier reste à découvert. Un taux global masque par ailleurs l'écart entre le cœur du produit et le code décoratif, et les fichiers générés ou de configuration gonflent artificiellement le résultat s'ils ne sont pas exclus.

Comment s'en servir utilement

Renoncez au chiffre unique pour l'ensemble du dépôt. Visez une couverture élevée, avec des tests réellement assertifs, sur les parties dont une panne coûte cher : calculs, règles métier, paiements, sécurité. Acceptez qu'elle soit faible ailleurs. Et suivez surtout la couverture du code modifié, bien plus révélatrice de la trajectoire d'un projet que la moyenne héritée du passé.