Une équipe rapporte fièrement une couverture de code de 95 %, puis envoie un bug dans une ligne qui était “couverte”. Ce n’est pas une contradiction. La couverture répond à une question précise : les tests ont-ils exécuté ce code ? Qu’ils aient vérifié le résultat est une tout autre question.

Nous avons utilisé Python avec cover.py 7.17 et pytest 9.2. Chaque numéro et rapport ci-dessous provient de notre propre course. Les idées s’appliquent dans n’importe quelle langue.

Qu’est-ce que la couverture du code ?

La couverture du code est le pourcentage de votre code qui s’exécute pendant l’exécution de vos tests automatisés. Un outil enregistre quelles lignes, et éventuellement quelles branches, ont été exécutées, puis signale ce qui a été manqué.

C’est plus utile à l’envers. Une faible couverture dans une zone vous indique avec certitude que les tests ne l’exercent pas. Une couverture élevée vous en dit beaucoup moins.

Types de couverture

Chaque niveau est plus strict que celui situé au-dessus. La plupart des équipes suivent la couverture des lignes et des succursales. La couverture des conditions et MC/DC apparaissent dans les normes aéronautiques et automobiles, où le support en outillage est spécialisé.

Le code que nous avons mesuré

def shipping_fee(total, is_member, express=False):
    if total < 0:
        raise ValueError("total cannot be negative")
    fee = 0 if total >= 1000 else 50
    if is_member:
        fee = max(fee - 25, 0)
    if express:
        fee += 100
    return fee

Notre premier fichier de test comportait deux tests :

def test_regular_order():
    assert shipping_fee(500, False) == 50

def test_member_express():
    assert shipping_fee(500, True, express=True) == 125

Nous l’avons exécuté avec la mesure de branche activée :

coverage run --branch -m pytest test_shipping.py
coverage report -m

Lecture du rapport

Name          Stmts   Miss Branch BrPart  Cover   Missing
---------------------------------------------------------
shipping.py       9      1      6      1    87%   3

• Stmts 9, Miss 1 : neuf instructions exécutables, dont une n’a jamais été exécutée.
• Branche 6, BrPart 1 : trois if décisions donnent six résultats possibles. Une décision n’allait que dans un sens.
• Manquant 3 : la ligne 3, la raise ValueError, n’a jamais été diffusée. Aucun test n’a donné un total négatif.

Le correctif est un test du chemin d’erreur. Nous avons également ajouté un test pour une commande importante :

def test_free_over_1000():
    assert shipping_fee(1000, False) == 0

def test_negative_total():
    with pytest.raises(ValueError):
        shipping_fee(-1, False)

Avec les deux fichiers, le rapport indiquait 100 % et aucune ligne manquante ni branche partielle. Les chemins d’erreur sont les découvertes classiques de couverture des écarts, c’est pourquoi les tests d’entrée non valide, conçus avec des techniques telles que le partitionnement d’équivalence, s’y associent si bien.

Ce que le rapport cachait

Regardez à nouveau le premier rapport. Il disait que seule la ligne 3 manquait. Mais les deux premiers tests en ont utilisé un total de 500, de sorte que la règle de livraison gratuite pour les commandes de 1 000 ou plus n’a jamais été testée, et le rapport ne l’a pas signalé.

La raison en est que fee = 0 if total >= 1000 else 50 se trouve sur une seule ligne. cover.py mesure les branches entre les lignes, donc une expression conditionnelle à l’intérieur d’une seule ligne compte comme une instruction exécutée. Si cette règle comportait un bug, tel que > au lieu de >=, la première suite aurait quand même affiché 87 % sans aucune indication. Les tests de la limite elle-même, comme décrit dans analyse des valeurs limites, sont ce qui la détecte.

Couverture à 100% sans contrôle

Ensuite, nous avons écrit un test délibérément médiocre qui appelle tous les chemins mais n’affirme rien :

def test_runs_everything_but_checks_nothing():
    shipping_fee(500, True, express=True)
    shipping_fee(1000, False)
    shipping_fee(500, False)
    try:
        shipping_fee(-1, False)
    except ValueError:
        pass

shipping.py       9      0      6      0   100%

Il a atteint 100 % de couverture de lignes et de succursales. La fonction pourrait renvoyer n’importe quel nombre et ce test réussirait quand même. Il s’agit de la limite fondamentale de la couverture : elle mesure l’exécution et non la vérification.

Pour mesurer si les tests détectent réellement les bogues, utilisez les tests de mutation. Un outil tel que Mutmut pour Python, PIT pour Java ou Stryker pour JavaScript apporte de petites modifications à votre code, comme retourner >= à >, et vérifie qu’un test échoue. Notre test sans assertion permettrait à chaque mutation de survivre.

Quel objectif fixer

Il n’existe pas de chiffre universellement correct. Conseils pratiques :

• Ne recherchez pas 100 %. Les derniers pourcentages signifient souvent tester du code trivial ou écrire des tests qui touchent simplement des lignes.
• De nombreuses équipes visent environ 70 à 85 % au total, avec des attentes plus élevées en matière de logique métier de base.
• Surveillez la tendance, pas le chiffre. La couverture qui diminue à chaque version est un signe d’avertissement.
• Exiger la couverture du nouveau code dans les demandes d’extraction plutôt que de forcer l’ancien code à s’afficher d’un seul coup.
• Excluez ce qui n’a pas d’importance, comme le code généré, avec des règles claires.

La loi de Goodhart s’applique : lorsqu’une mesure devient un objectif, elle cesse d’être une bonne mesure. Les cibles difficiles encouragent les tests comme notre exemple sans assertion.

Outils par langue

Couverture en CI

Exécutez la couverture dans le cadre de votre pipeline CI et publiez le rapport afin que les réviseurs puissent voir quelles nouvelles lignes n’ont pas été testées. Avec cover.py, coverage report --fail-under=80 échoue la construction en dessous d’un seuil. Gardez tout seuil modeste et combinez-le avec une règle sur le nouveau code, afin qu’un seul gros fichier hérité ne bloque pas chaque modification.

Au-delà de la couverture : de meilleures questions à poser

• Les tests couvrent-ils les parties du code à risque et fréquemment modifiées ?
• Les limites et les chemins d’erreur sont-ils testés, et pas seulement le chemin heureux ?
• Un test échouerait-il si cette ligne était fausse ?
• Les tests sont-ils suffisamment rapides et stables pour être exécutés à chaque modification ?

Ceux-ci appartiennent à n’importe quelle stratégie de test. La couverture permet de répondre uniquement à la première.

Exclusion de code et lecture de rapports HTML

Certains codes ne valent pas la peine d’être testés directement, comme les aides au débogage ou un bloc qui ne s’exécute que lorsqu’un script est démarré manuellement. cover.py vous permet d’exclure des lignes avec un commentaire :

if __name__ == "__main__":  # pragma: no cover
    main()

Vous pouvez également définir des exclusions et les dossiers sources à mesurer dans la configuration, par exemple dans pyproject.toml :

[tool.coverage.run]
branch = true
source = ["shop"]

[tool.coverage.report]
show_missing = true
exclude_also = ["if TYPE_CHECKING:"]

Utilisez les exclusions avec parcimonie et examinez-les comme du code. Chacun est une décision selon laquelle certaines lignes ne seront jamais vérifiées. L’exclusion d’un gestionnaire d’erreurs difficile à tester simplement pour augmenter le nombre va à l’encontre de l’objectif.

Pour le travail quotidien, le rapport HTML est plus utile que le tableau terminal. Exécutez coverage html et ouvrez htmlcov/index.html. Chaque fichier est affiché avec les lignes exécutées en vert, les lignes manquées en rouge et les branches partielles en jaune, afin que vous puissiez voir d’un coup d’œil lequel if n’a jamais pris son autre chemin. De nombreux éditeurs peuvent également afficher une couverture dans la marge, ce qui rend les espaces visibles pendant que vous écrivez le code plutôt qu’après.

Couverture avant la refactorisation

La couverture est également un contrôle de sécurité avant la refactorisation. Si vous envisagez de restructurer un module, consultez d’abord son rapport. Les zones rouges ne comportent aucun test pour vous avertir si le comportement change. Ajoutez donc des tests de caractérisation qui capturent le comportement actuel avant de commencer. Utilisée de cette manière, la couverture cesse d’être une cible et devient un outil de planification pratique.

Le même rapport est utile lorsqu’un bug échappe à la production. Recherchez la ligne où se trouve le bug et vérifiez si un test l’a exécuté. Sinon, vous avez trouvé une lacune qui mérite d’être comblée. Si un test l’a exécuté, le problème est une assertion faible, ce qui est exactement la situation montrée par notre exemple sans assertion. Les deux réponses vous indiquent comment améliorer la suite.

Pour conclure

La couverture du code est une lampe de poche, pas une note. Utilisez la couverture des branches pour trouver du code qu’aucun test ne touche, en particulier la gestion des erreurs, puis écrivez des tests qui font de véritables assertions. Si vous vous souvenez d’un résultat de notre analyse, notez celui-ci : une couverture de 100 % a été atteinte par un test qui n’a rien vérifié.

Questions fréquentes

Continuez à apprendre