問題は、ビルドが赤くなること自体ではなく、その原因が新たなリグレッションなのか、断続的なテストなのか、それとも調査に必要な証拠を失わせたテストホストのクラッシュなのかを把握することにあります。.NET Blogでは、Microsoft.Testing.Platform（MTP）によって、単に長いログの一覧を表示するのではなく、開発者、レビュアー、継続的インテグレーションツールにとってテストレポートをより有用にする方法を説明しています。
これらの実践方法は、GitHub ActionsまたはAzure DevOpsを使用し、失敗に関する情報をプルリクエスト内の意思決定地点に届けたいチームを対象としています。また、プラットフォームでは1回の実行から複数のレポート形式を生成でき、プログラム、ダッシュボード、開発ツールが安定して利用できる構造化された出力を提供できます。
ビルド履歴を使用してリグレッションと断続的な失敗を区別する
Azure DevOpsではすでにTestsタブにテストの証拠が表示されますが、レポーターに履歴期間を渡すことで、各失敗にコンテキストを追加できます。--report-azdo-flaky-history 14オプションを使用すると、プラットフォームは過去14日間のパイプライン履歴を照会し、断続的に失敗したテストと、同様の履歴を持たないテストを区別します。
断続的なテストには[flaky: failed 3/20 in last 14d]というラベルが表示される場合があります。一方、このような履歴を持たない失敗には[REGRESSION]というラベルが付けられます。これにより、レビュアーは適切な経路から調査を開始できます。履歴のない失敗は潜在的なリグレッションとして直ちに注意を要する一方、繰り返し発生する失敗は既知の記録から調査を始められます。
チームが継続的インテグレーションにおけるこの動作を変更したい場合は、--report-azdo-demote-known-flakyオプションを使用して、既知の断続的な失敗を警告に変換し、リグレッションはエラーとして維持できます。ただし、情報源では判断を明確にすべきだと強調しています。履歴をレビュアーへの案内だけに使用するのか、それとも失敗の重大度を自動的に変更するのか、という点です。testfxのパイプラインでは、履歴コメントを使用しつつ、すべての失敗状態をビルドのブロッカーとして維持しました。
同じ履歴は、--report-azdo-slow-test-historyによって遅いテストの検出にも使用されます。このオプションは、調整可能な倍率と最小実行回数のしきい値を用いて、各テストを過去のパフォーマンスと比較します。そのため、1回のコールド実行だけで不正確な警告が発生することはありません。
テストホストがクラッシュした場合でも証拠を保持する
TRX形式の結果は実行の最後にシリアライズされていたため、重大なクラッシュによってレポート全体が失われる可能性がありました。現在は結果が生成中にディスクへ書き込まれ、クラッシュダンプ拡張機能と組み合わせることで、ホストが停止した際に部分的なレポートを終了できます。
dotnet test --report-trx --crashdump
これにより、完了したすべてのテストと、クラッシュ時に実行中だったテストの一覧を含む有効なTRXファイルが生成されます。また、拡張機能は.crash.sequence.log拡張子のファイルを書き込み、各テストの開始と終了を記録します。これにより、複数のテストを並列実行している場合でも、開始したまま終了しなかったテストを特定できます。
添付ファイルもこの処理の対象です。クラッシュダンプ、停止コメント、テスト拡張機能のファイルは、パスがWindows MAX_PATHの制限を超えた場合でも、.NET Framework上で黙って無視されることがなくなりました。添付ファイルをコピーできない場合はコンソールに表示され、TRXファイル内だけに記録されたままになることはありません。その結果、未完了の実行は未完了であることが明確に示され、不足している証拠を隠す緑色のレポートのように見えることがありません。
利用者に応じてレポート形式を選択する
1回の実行で、別途変換手順を設けずに複数の形式を有効にできます。TRX形式は.NETツールに適しており、HTMLは直接確認する用途に適しています。JUnit XMLとCTRF JSONは、ダッシュボードや技術をまたいだ自動化に役立ちます。CTRFは、.NETの結果と他の言語の結果を集約するための共通JSONスキーマを提供します。
継続的インテグレーションシステムは、結果表示でTRXとJUnitを読み取ります。一方、HTMLとCTRFはダウンロード可能なファイルとして、またはダッシュボードで利用できます。Azure DevOpsでは、--report-azdo-upload-artifacts filesオプションによって、結果証拠ファイルを自動的にアップロードできます。また、複数のターゲットフレームワークを対象とするプロジェクトで結果が衝突しないよう、--report-<format>-filenameオプションと{asm}や{tfm}などのプレースホルダーを使用してファイル名を付ける必要があります。
出力を安定させ、自動化可能にする
--list-tests jsonオプションは、検出されたテストとそのソース位置を記述する、スキーマバージョン付きのドキュメントを提供します。これは、バージョン間で変化する可能性があるコンソールテキストを解析する代わりに、テストの選択、変更影響分析、開発環境との統合に利用できる安定した入力となります。
MTPの出力はエージェント環境や言語モデルにも適応します。バナー、ANSI文字、進行状況のアニメーションを非表示にし、既定では失敗したテストのみのstdoutとstderrを表示します。この動作は、NO_COLOR、--ansi、--progressの各オプションで制御できます。
レポートポリシーを固定し、互換性を確認する
記事では、まず1つのテストプロジェクトでMTP 2.3以降を試し、GitHub Actionsでは--report-gh、Azure DevOpsでは--report-azdoを有効にすることを推奨しています。ポリシーを選択した後は、設定をリポジトリ内のtestconfig.jsonファイルに保存し、ローカル実行とCI実行で同じレポートを生成できるようにします。また、Directory.Build.propsを使用してすべてのテストプロジェクトに統一設定を適用したり、AllMicrosoftプロファイルを使用して安定した拡張機能のセットを有効にしたりできます。JUnitとCTRFは引き続き任意です。
MSTest.Sdkを使用していないチームは、レポーターのパッケージバージョンがテストフレームワークの対象とするMTPのバージョンと一致していることを確認する必要があります。MTP 2.xのサポートは、MSTest.TestAdapter 4.0.0、NUnit3TestAdapter 6.0.1、TUnit 1.7.16、YoloDev.Expecto.TestSdk 0.16.0、およびxunit.v3 4.0のプレビュー版に対応しています。また、MTPプロジェクトとVSTestプロジェクトを混在させるソリューションはサポートされていないため、リポジトリレベルでMTP実行への参加を設定する必要があります。
Azure DevOpsの履歴オプションには、SYSTEM_ACCESSTOKEN: $(System.AccessToken)トークンが必要です。これがない場合も実行は継続されますが、履歴コメントはスキップされます。既存のパイプラインでは、テスト結果の公開タスクとファイルの公開タスクを対応するMTPオプションに置き換えられますが、コードカバレッジの公開は置き換えられません。そのため、PublishCodeCoverageResults@2は維持する必要があります。また、直接公開とPublishTestResults@2を同時に有効にしないでください。同じビルドに対して2つの別個のテスト実行が作成されるためです。