Das Problem liegt nicht darin, dass ein Build rot wird, sondern darin, zu wissen, ob die Ursache eine neue Regression, ein intermittierender Test oder ein Absturz des Testhosts ist, durch den die für die Untersuchung erforderlichen Belege verloren gingen. Der .NET Blog zeigt, wie Microsoft.Testing.Platform (MTP) Testberichte für Entwickler, Reviewer und Continuous-Integration-Tools nützlicher machen kann, statt lediglich eine lange Liste von Protokollen anzuzeigen.
Diese Vorgehensweisen richten sich an Teams, die GitHub Actions oder Azure DevOps verwenden und Fehlerinformationen an den Entscheidungspunkt innerhalb eines Pull Requests bringen möchten. Die Plattform ermöglicht außerdem, aus einem einzigen Lauf mehrere Berichtsformate zu erzeugen und strukturierte Ausgaben bereitzustellen, die von Programmen, Dashboards und Entwicklungstools zuverlässig verarbeitet werden können.
Verwenden Sie die Build-Historie, um Regressionen von intermittierenden Fehlern zu unterscheiden
Azure DevOps zeigt Testbelege bereits auf der Registerkarte „Tests“ an. Das Übergeben eines historischen Zeitfensters an den Reporter fügt jedoch jedem Fehler Kontext hinzu. Bei Verwendung der Option --report-azdo-flaky-history 14 fragt die Plattform die Pipeline-Historie der letzten 14 Tage ab und unterscheidet anschließend einen intermittierend fehlgeschlagenen Test von einem Test ohne vergleichbare Historie.
Ein intermittierender Test kann mit dem Label [flaky: failed 3/20 in last 14d] angezeigt werden, während ein Fehler ohne diesen Verlauf das Label [REGRESSION] erhält. Dadurch kann der Reviewer die Untersuchung auf dem passenden Pfad beginnen: Ein Fehler ohne Historie erfordert als mögliche Regression sofortige Aufmerksamkeit, während ein wiederkehrender Fehler von seinem bekannten Verlauf ausgehend untersucht wird.
Wenn das Team dieses Verhalten der Continuous Integration ändern möchte, wandelt die Option --report-azdo-demote-known-flaky bekannte intermittierende Fehler in Warnungen um, während Regressionen Fehler bleiben. Die Quelle betont jedoch, dass diese Entscheidung ausdrücklich getroffen werden sollte: Soll die Historie lediglich zur Orientierung des Reviewers dienen, oder soll sie den Schweregrad des Fehlers automatisch ändern? In der testfx-Pipeline wurden historische Kommentare verwendet, während alle Fehlerzustände weiterhin den Build blockierten.
Dieselbe Historie wird mit --report-azdo-slow-test-history zur Erkennung langsamer Tests verwendet. Die Option vergleicht jeden Test mit seiner bisherigen Leistung und verwendet dabei einen anpassbaren Multiplikator sowie eine Mindestanzahl von Ausführungen, damit ein einzelner kalter Lauf keinen ungenauen Alarm auslöst.
Bewahren Sie Belege auf, wenn der Testhost abstürzt
TRX-Ergebnisse wurden am Ende des Laufs serialisiert, sodass ein schwerwiegender Absturz den gesamten Bericht verlieren konnte. Nun werden die Ergebnisse während ihrer Erstellung auf die Festplatte geschrieben. In Verbindung mit der Crash-Dump-Erweiterung kann der unvollständige Bericht abgeschlossen werden, wenn der Host stoppt:
dotnet test --report-trx --crashdump
Dadurch entsteht eine gültige TRX-Datei mit allen abgeschlossenen Tests sowie einer Liste der Tests, die zum Zeitpunkt des Absturzes ausgeführt wurden. Die Erweiterung schreibt außerdem eine Datei mit der Endung .crash.sequence.log, die den Beginn und das Ende jedes Tests protokolliert. Dies hilft, den Test zu bestimmen, der begonnen, aber nicht beendet wurde, selbst wenn mehrere Tests parallel ausgeführt werden.
Auch Anhänge werden verarbeitet. Crash-Dumps, Stoppkommentare und Dateien von Test-Erweiterungen werden unter .NET Framework nicht mehr stillschweigend ignoriert, wenn der Pfad das Limit Windows MAX_PATH überschreitet. Kann ein Anhang nicht kopiert werden, wird dies in der Konsole angezeigt, statt nur in der TRX-Datei erwähnt zu werden. Dadurch wird ein unvollständiger Lauf eindeutig als unvollständig angezeigt und nicht wie ein grüner Bericht, der fehlende Belege verbirgt.
Wählen Sie das Berichtsformat entsprechend dem konsumierenden System
Ein einzelner Lauf kann mehrere Formate aktivieren, ohne einen separaten Konvertierungsschritt. Das Format TRX eignet sich für .NET-Tools, während HTML für die direkte Prüfung geeignet ist und JUnit XML sowie CTRF JSON für Dashboards und technologieübergreifende Automatisierung nützlich sind. CTRF stellt ein gemeinsames JSON-Schema bereit, um .NET-Ergebnisse mit Ergebnissen anderer Sprachen zusammenzuführen.
Continuous-Integration-Systeme lesen TRX- und JUnit-Formate in Ergebnisansichten; HTML und CTRF werden als Dateien angezeigt, die heruntergeladen oder in Dashboards verwendet werden können. In Azure DevOps kann die Option --report-azdo-upload-artifacts files Dateien mit Ergebnisbelegen automatisch hochladen. Außerdem sollten Dateien mit der Option --report-<format>-filename und Platzhaltern wie {asm} und {tfm} benannt werden, damit Ergebnisse in Projekten mit mehreren Ziel-Frameworks nicht miteinander kollidieren.
Machen Sie Ausgaben stabil und automatisierbar
Die Option --list-tests json stellt ein Dokument mit versioniertem Schema bereit, das die entdeckten Tests und ihre Quellcodepositionen beschreibt. Dies ist ein stabiler Eingang für die Testauswahl, die Analyse der Änderungsauswirkungen und die Integration in Entwicklungsumgebungen, statt den sich zwischen Versionen möglicherweise ändernden Konsolentext zu analysieren.
Die Ausgaben von MTP passen sich Agenten- und Sprachmodellumgebungen an: Banner, ANSI-Zeichen und Fortschrittsbewegungen werden ausgeblendet, und standardmäßig werden stdout- und stderr-Ausgaben nur für fehlgeschlagene Tests angezeigt. Das Verhalten kann über NO_COLOR sowie die Optionen --ansi und --progress gesteuert werden.
Legen Sie eine Berichtsrichtlinie fest und überprüfen Sie die Kompatibilität
Der Beitrag empfiehlt, MTP 2.3 oder eine neuere Version zunächst in einem Testprojekt auszuprobieren und anschließend --report-gh in GitHub Actions oder --report-azdo in Azure DevOps zu aktivieren. Nach der Auswahl der Richtlinie werden die Einstellungen in der Datei testconfig.json im Repository gespeichert, sodass lokale und CI-Läufe dieselben Berichte erzeugen. Mit Directory.Build.props können außerdem einheitliche Einstellungen auf alle Testprojekte angewendet werden. Alternativ kann das Profil AllMicrosoft verwendet werden, um die stabile Gruppe von Erweiterungen zu aktivieren; JUnit und CTRF bleiben optional.
Teams, die MSTest.Sdk nicht verwenden, sollten überprüfen, ob die Versionen der Reporter-Pakete mit der MTP-Version übereinstimmen, auf die das Test-Framework abzielt. MTP 2.x wird von MSTest.TestAdapter 4.0.0, NUnit3TestAdapter 6.0.1, TUnit 1.7.16, YoloDev.Expecto.TestSdk 0.16.0 und Preview-Versionen von xunit.v3 4.0 unterstützt. Außerdem unterstützt die Lösung keine Mischung aus MTP- und VSTest-Projekten. Daher sollte die Teilnahme an MTP-Läufen auf Repository-Ebene festgelegt werden.
Die Azure-DevOps-Historienoptionen benötigen das Token SYSTEM_ACCESSTOKEN: $(System.AccessToken). Ohne dieses Token wird der Lauf fortgesetzt, historische Kommentare werden jedoch übersprungen. In bestehenden Pipelines können Aufgaben zur Veröffentlichung von Testergebnissen und Dateien durch die entsprechenden MTP-Optionen ersetzt werden. Die Veröffentlichung der Codeabdeckung wird jedoch nicht ersetzt; daher muss PublishCodeCoverageResults@2 beibehalten werden. Außerdem sollten die direkte Veröffentlichung und PublishTestResults@2 nicht gleichzeitig aktiviert werden, da dadurch zwei separate Testläufe für denselben Build erstellt werden.