Pendant des années, consulter la couverture de code sur Azure Pipelines voulait dire télécharger un rapport HTML en artefact et le faire tourner en local pour y voir quelque chose de lisible. Depuis le sprint 278, ce détour n’est plus nécessaire : l’onglet Code Coverage a été refondu, avec une navigation par dossier/fichier, un aperçu du code source ligne par ligne et une vraie vue de détail par module. Le déploiement s’étale sur 2 à 3 semaines selon les organisations, donc tu l’as sans doute déjà sous les yeux — ou tu l’auras d’ici peu.
Ce qui change concrètement
L’ancien onglet se contentait d’un pourcentage global et d’un lien vers le rapport HTML brut. La nouvelle expérience ajoute trois choses utiles au quotidien : une arborescence dossier > fichier avec le taux de couverture agrégé à chaque niveau, une visualisation du code source où les lignes couvertes, partiellement couvertes et non couvertes sont surlignées directement, et une vue Détails qui permet de filtrer par module et par configuration de build. Le toggle vers l’ancien rapport HTML reste disponible, au cas où tu aurais des scripts ou des habitudes qui en dépendent.
Formats pris en charge pour profiter de l’expérience complète : Cobertura, JaCoCo, Clover, gcov, pcov et XML générique. Si tes rapports sont en .coverage, .cjson ou .covx, tu gardes l’onglet Code Coverage avec drill-down, mais seulement quand les mappings source sont disponibles — sinon tu restes sur l’ancien comportement.
Ce qu’il faut pour en profiter
Rien de nouveau à installer : la tâche Publish Code Coverage Results v2 suffit, et c’est elle qui alimente la nouvelle UI. Les tâches intégrées Visual Studio Test, .NET Core, Ant, Maven, Gulp, Grunt et Gradle savent déjà publier leur couverture dans un format compatible. Si ton pipeline utilise encore la v1 de la tâche, c’est le bon moment pour migrer — la v1 ne déclenche ni la nouvelle expérience ni la diff coverage sur les pull requests.
La diff coverage sur les pull requests, le vrai gain
Le point le plus intéressant n’est pas visuel, il est fonctionnel : tu peux maintenant imposer un seuil de couverture minimum sur les lignes modifiées d’une PR, pas sur l’ensemble du dépôt. Ça évite le découragement classique d’un vieux projet à 40 % de couverture globale où personne ne touchera jamais ce chiffre, tout en empêchant que du code neuf parte sans tests. La configuration se fait via un fichier à la racine du dépôt :
coverage:
status:
comments: on # Off par défaut : poste le détail fichier par fichier en commentaire de PR
diff:
target: 60% # Par défaut 70% : seuil minimum de couverture sur les lignes modifiées
Un target à 60 % plutôt que 70 % n’a rien d’arbitraire si ton équipe sort d’un legacy peu testé : mieux vaut un seuil réaliste qu’on respecte vraiment qu’un seuil ambitieux qu’on désactive après la première PR bloquée pour de mauvaises raisons.
Les limites à connaître avant de t’enthousiasmer
Cette diff coverage sur PR ne fonctionne aujourd’hui que pour Azure Repos — si ton code est sur GitHub avec un pipeline Azure DevOps qui le build, tu n’y as pas accès. Pour le reste, trois plafonds à garder en tête : 10 Go de pièces jointes par build pipeline au-delà desquels rien n’est traité, 7 Mo par fichier HTML au-delà desquels le rapport ne se charge plus dans la vue (télécharge l’artefact à la place), et plus de 100 fichiers modifiés dans une PR qui peut faire rester bloqué le contrôle de couverture — une limite qui va surprendre sur une grosse PR de refactoring. Et si ton pipeline est multi-stage, les résultats de couverture ne sont disponibles qu’une fois l’ensemble du pipeline terminé, pas stage par stage.
Dernier point pour les projets qui mixent .NET Core et .NET Framework : voir des DLL en double dans la vue est normal, ce n’est pas un bug de la nouvelle expérience.
FAQ
Dois-je changer quelque chose dans mon pipeline existant pour voir la nouvelle interface ?
Non, si tu utilises déjà Publish Code Coverage Results v2 avec un format supporté, la nouvelle vue s’affiche automatiquement dès que le rollout atteint ton organisation.
La diff coverage va-t-elle bloquer mes PR existantes dès son activation ?
Seulement si tu configures explicitement azurepipelines-coverage.yml avec une politique de branche associée à ce contrôle. Sans ce fichier, rien ne change dans ton comportement actuel.
Que se passe-t-il si mon rapport HTML dépasse 7 Mo ?
La vue HTML intégrée ne le charge pas. Tu dois télécharger l’artefact de rapport pour le consulter en local — vérifie aussi que tu ne publies pas des rapports non minifiés par erreur.
Pour aller plus loin
Si tu gères déjà tes agents de build via Managed DevOps Pools, c’est l’occasion de vérifier que tes images incluent bien les bons outils de génération de rapports de couverture (voir notre article sur Managed DevOps Pools). Et si Copilot Code Review tourne déjà sur tes PR (notre article sur sa mise en preview publique), la diff coverage est son complément naturel : l’un relit la qualité du code, l’autre vérifie que les lignes changées sont testées. Configure au moins un seuil réaliste sur tes dépôts Azure Repos actifs cette semaine — le fichier YAML tient en quatre lignes, il n’y a pas de bonne raison d’attendre.
Laisser un commentaire