制限事項

TestDetta は、把握できないものがある場合は多めに選択します。このページではそのようなケースを一覧にしています。選択が必要以上に広くなるのはどのような場合か、また手書きのパターンによってテストが隠れてしまう数少ないケースを確認できます。

テストフレームワークとテストランナー

dotnet test の両方のテストランナーに対応しています。テストランナーは global.json から読み取られます("test": { "runner": "Microsoft.Testing.Platform" }。.NET 10 SDK で xUnit v3 を使う場合は必須です)。

各テストプロジェクトは、その場所かそれより上にある最も近い global.json のディレクトリでビルド・実行されます。そのため、ソリューションの隣に置かれたファイル(src/global.json)は、そこで作業する開発者の場合と同じように扱われます。--dry-run では、このようなコマンドが (cd src && dotnet test ...) のように出力されます。

記録と選択は、xUnit v2(VSTest)、xUnit v3 と TUnit(Microsoft.Testing.Platform)、そして両方のテストランナー上の MSTest と NUnit で、エンドツーエンドでテストされています。フレームワーク独自の並列実行を有効にしたプロジェクトも含みます。

記録中に失敗するテスト

記録中に失敗したテストクラスは、そのプロジェクトが影響を受ける場合は常に選択されます。失敗したテストは途中で止まるため、カバレッジが不完全になるからです。

テストが失敗し、どれが失敗したかを示す TRX レポートがない場合(Microsoft.Testing.Extensions.TrxReport なしで Microsoft.Testing.Platform 上の NUnit を使う場合)は、マップは使用されず、選択は名前によるものにフォールバックします。

プロセスごとに 1 回だけ実行されるコード

キャッシュ、遅延初期化されるシングルトン、EF のモデル構築は、テストプロセスごとに 1 回だけ実行され、それを最初に引き起こしたテストクラスに記録されます。静的コンストラクターやキャッシュを埋める呼び出し(ConcurrentDictionary.GetOrAdd、Lazy<T>.Value、LazyInitializer、ConditionalWeakTable、IMemoryCache.GetOrCreate)の中で実行されたコードへの変更や、記録プロセスごとに 1 つのテストクラスしか実行しなかったコンストラクターや静的メンバーへの変更は、代わりに名前でたどります。

TryGetValue で確認する Dictionary のような手書きのキャッシュでは、その利用者が隠れてしまう可能性が残ります。既定のブランチでは引き続き完全なテストスイートを実行してください。記録がそれを行います。

プロジェクトファイル

プロジェクトファイルは、参照、コンパイル対象と埋め込みの項目、アセンブリ名、ターゲットフレームワークを得るために、既定の構成で、復元を行わずに MSBuild によって評価されます(dotnet msbuild の呼び出し 1 回で、結果は .testdetta/cache にキャッシュされます)。

コードからはわからないもの

TestDetta が把握できるのは、ソースコード、プロジェクトファイル、そして記録中にテストが実行した内容です。次のものは把握できません。

パッケージのバージョン変更は把握されます。Directory.Packages.props の PackageVersion の変更はそのパッケージを参照するプロジェクトを実行し、PackageReference の変更はプロジェクトファイルへの変更として扱われます。

プリプロセッサシンボル

C# ファイルは、各ターゲットフレームワークの実際のプリプロセッサシンボルに加え、シンボルなしの場合と、#if で指定されているすべてのシンボルを定義した場合でも解析されます。そのため、どの条件が有効なコードも把握されます。

スキップされたテスト

マップの記録中にスキップされたテストにはカバレッジがありません。すべてのテストがスキップされたクラスは、実行される可能性のある別のプラットフォームでは選択され、記録したプラットフォームではスキップされます。Docker デーモンがないなど、それ以外の理由でスキップされたテストは、そのテストが実行される環境で記録した場合にのみカバーされます。

ソースジェネレーター

ソースジェネレーターが生成したコードはソースツリーにありません。td record は記録したアセンブリの PDB(ポータブルまたは埋め込み)からそのコードを読み取り、そこに出現する名前をマップに保持します。そのため、名前によるトレースで生成された呼び出し元も把握できます。ポータブル PDB なしでビルドされたアセンブリからは何も得られません。

F# と Visual Basic

F# と Visual Basic のプロジェクトはプロジェクトグラフには含まれますが、そのコードは分析されません。これらのプロジェクトが影響を受けた場合、それに依存するものはすべて丸ごと実行されます。