Le problème ne réside pas dans l’apparition d’un build rouge en soi, mais dans le fait de savoir s’il est dû à une nouvelle régression, à un test intermittent ou au crash de l’hôte de test qui a supprimé les éléments nécessaires à l’investigation. Le .NET Blog explique comment Microsoft.Testing.Platform, ou MTP, peut rendre les rapports de tests plus utiles aux développeurs, aux réviseurs et aux outils d’intégration continue, au lieu de se contenter d’afficher une longue liste de journaux.
Ces pratiques ciblent les équipes qui utilisent GitHub Actions ou Azure DevOps et qui souhaitent que les informations d’échec parviennent au point de décision au sein de la demande de fusion. La plateforme permet également de produire plusieurs formats de rapport à partir d’une seule exécution et de fournir des sorties structurées que les programmes, les tableaux de bord et les outils de développement peuvent exploiter de manière stable.
Utiliser l’historique du build pour distinguer une régression d’une défaillance intermittente
Azure DevOps affiche déjà les éléments probants des tests dans l’onglet Tests, mais transmettre une fenêtre historique au rapporteur ajoute du contexte à chaque échec. Lors de l’utilisation de l’option --report-azdo-flaky-history 14, la plateforme interroge l’historique du pipeline sur 14 jours, puis distingue le test qui a échoué de manière intermittente du test qui ne dispose pas d’un historique similaire.
Le test intermittent peut apparaître avec l’étiquette [flaky: failed 3/20 in last 14d], tandis que l’échec qui ne possède pas cet historique reçoit l’étiquette [REGRESSION]. Cela aide le réviseur à commencer l’investigation sur la voie appropriée : un échec sans historique nécessite une attention immédiate en tant que régression potentielle, tandis qu’un échec récurrent commence par son historique connu.
Si l’équipe souhaite modifier ce comportement de l’intégration continue, l’option --report-azdo-demote-known-flaky transforme les défaillances connues comme intermittentes en avertissements, tout en conservant les régressions comme erreurs. Mais la source souligne que la décision doit être explicite : voulons-nous utiliser l’historique uniquement pour orienter le réviseur, ou voulons-nous qu’il modifie automatiquement le niveau de gravité de l’échec ? Dans le pipeline testfx, les commentaires historiques ont été utilisés tout en conservant tous les cas d’échec comme bloquants pour le build.
Le même historique sert à détecter les tests lents grâce à --report-azdo-slow-test-history. L’option compare chaque test à ses performances précédentes, à l’aide d’un multiplicateur configurable et d’un nombre minimal d’exécutions, afin qu’une seule exécution à froid ne déclenche pas une alerte inexacte.
Conserver les éléments probants lorsque l’hôte de test plante
Les résultats au format TRX étaient sérialisés à la fin de l’exécution ; un crash grave pouvait donc entraîner la perte de l’intégralité du rapport. Désormais, les résultats sont écrits sur le disque au fur et à mesure de leur production et, en combinaison avec l’extension de vidage sur incident, le rapport partiel peut être finalisé lorsque l’hôte s’arrête :
dotnet test --report-trx --crashdump
Il en résulte un fichier TRX valide contenant tous les tests terminés, ainsi qu’une liste des tests qui étaient en cours d’exécution au moment du crash. L’extension écrit également un fichier portant l’extension .crash.sequence.log, qui enregistre le début et la fin de chaque test, ce qui aide à déterminer quel test a commencé sans se terminer, même lorsque plusieurs tests s’exécutent en parallèle.
Le traitement concerne également les pièces jointes. Les vidages sur incident, les commentaires d’arrêt et les fichiers des extensions de test ne sont plus ignorés silencieusement sur .NET Framework lorsque le chemin dépasse la limite Windows MAX_PATH. Si une pièce jointe ne peut pas être copiée, cela apparaît dans la console au lieu de rester mentionné uniquement dans le fichier TRX. Ainsi, une exécution incomplète apparaît clairement comme telle et ne ressemble pas à un rapport vert dissimulant des éléments probants manquants.
Choisir le format du rapport en fonction de son consommateur
Une seule exécution peut activer plusieurs formats sans étape de conversion distincte. Le format TRX convient aux outils .NET, tandis que le format HTML est adapté à l’inspection directe et que JUnit XML et CTRF JSON sont utiles aux tableaux de bord et à l’automatisation intertechnologies. CTRF fournit un schéma JSON commun pour regrouper les résultats .NET avec ceux d’autres langages.
Les systèmes d’intégration continue lisent les formats TRX et JUnit dans les vues de résultats, tandis que HTML et CTRF apparaissent comme des fichiers pouvant être téléchargés ou utilisés dans des tableaux de bord. Dans Azure DevOps, l’option --report-azdo-upload-artifacts files permet de téléverser automatiquement les fichiers contenant les éléments probants des résultats. Il convient également de nommer les fichiers à l’aide de l’option --report-<format>-filename et d’espaces réservés tels que {asm} et {tfm}, afin d’éviter les conflits de résultats dans les projets ciblant plusieurs frameworks d’exécution.
Rendre les sorties stables et automatisables
L’option --list-tests json fournit un document dont le schéma versionné décrit les tests détectés et leurs emplacements sources. Il constitue une interface stable pour sélectionner les tests, analyser l’impact des modifications et intégrer les environnements de développement, au lieu d’analyser le texte de la console, qui peut changer d’une version à l’autre.
Les sorties de MTP s’adaptent aux environnements d’agents et aux modèles de langage : elles masquent la bannière, les caractères ANSI et l’animation de progression, et affichent par défaut les sorties stdout et stderr uniquement pour les tests échoués. Le comportement peut être contrôlé avec NO_COLOR et les options --ansi et --progress.
Centraliser la politique de rapports et vérifier la compatibilité
L’article recommande d’essayer MTP 2.3 ou une version ultérieure dans un projet de test, puis d’activer --report-gh dans GitHub Actions ou --report-azdo dans Azure DevOps. Après avoir choisi la politique, les paramètres sont enregistrés dans un fichier testconfig.json au sein du dépôt, afin que les exécutions locales et les exécutions CI produisent les mêmes rapports. Il est également possible d’utiliser Directory.Build.props pour appliquer des paramètres uniformes à tous les projets de test, ou d’utiliser le profil AllMicrosoft pour activer l’ensemble stable des extensions, tandis que JUnit et CTRF restent facultatifs.
Les équipes qui n’utilisent pas MSTest.Sdk doivent vérifier la correspondance entre les versions des packages de rapporteurs et la version de MTP ciblée par le framework de test. La prise en charge de MTP 2.x s’étend à MSTest.TestAdapter 4.0.0, NUnit3TestAdapter 6.0.1, TUnit 1.7.16, YoloDev.Expecto.TestSdk 0.16.0 et aux versions préliminaires de xunit.v3 4.0. De même, la solution ne prend pas en charge le mélange de projets MTP et VSTest ; il convient donc de configurer l’adhésion à l’exécution MTP au niveau du dépôt.
Les options d’historique Azure DevOps nécessitent le jeton SYSTEM_ACCESSTOKEN: $(System.AccessToken). Sans lui, l’exécution se poursuit, mais les commentaires historiques sont ignorés. Dans les pipelines actuels, les tâches de publication des résultats de test et de publication des fichiers peuvent être remplacées par les options MTP correspondantes, mais la publication de la couverture du code ne l’est pas ; il faut donc conserver PublishCodeCoverageResults@2. Il ne faut pas non plus activer simultanément la publication directe et PublishTestResults@2, car cela crée deux exécutions de test distinctes pour le même build.