特定のメソッドを直接的または間接的に呼び出す可能性のあるすべての単体テストを見つけるにはどうすればよいですか? メソッドを変更するとき、実行するのに最適なテストを知りたいです。これにはツールが必要です。
多くのインターフェイスがあるため、インターフェイスを実装するクラスに埋め込みメソッドのパスが少なくとも 1 つある場合に、インターフェイスのメソッドを呼び出すすべての単体テストに関心があります。
つまり、変更したメソッドが結果に影響しないことをツールが証明できない場合、すべての単体テストのリストが必要です。
(私たちは .net で nUnit を使用しており、多くの遅い単体テストがあります。すべての単体テストを高速にリファクタリングするまでには何年もかかります)
以下も参照してください。
Visual Studio 2010 には、まさにこの機能があります。
nunit を使用しているため、この手法を試して MSTest を実行することもできます: http://msdn.microsoft.com/en-gb/magazine/cc163643.aspx#S4
必要なのは、各テストとそれが実行するコードの間の関係です。
これは静的に計算できますが、難しく、それを行うツールを知りません。さらに悪いことに、そのようなツールがあった場合、テストの影響を判断するための静的分析は、実際にはテスト自体を実行するよりも時間がかかる可能性があるため、魅力的な方向には見えません。
ただし、これはテスト カバレッジ ツールを使用して計算できます。個々のテストごとに、そのテストを実行し (合格すると仮定します)、テスト カバレッジ データを収集します。これで、「テスト i のカバレッジ c がある」というペア (t_i,c_i) がたくさんあります。
コード ベースが変更された場合、テスト データ カバレッジ セットを参照できます。簡単なチェック: (t_i,c_i) の場合、c_i がファイル F に言及しており、F が変更されている場合、t_i を再度実行する必要があります。ほぼすべての表現でテスト カバレッジ データが与えられた場合、これは抽象的に簡単に検出できます。ほとんどのテスト カバレッジ ツールは、テスト カバレッジ データの保存方法を具体的に示していないため、これは実際には見た目よりも困難です。
実際、理想的には、c_i が F のプログラム要素に言及し、そのプログラム要素が変更された場合、t_i を再度実行する必要があります。
当社のSD テスト カバレッジ ツールは、メソッドのレベルで Java および C# にこの機能を提供します。パッケージ化した実際のテストを、収集したテスト カバレッジ ベクトルに関連付けるには、スクリプトをセットアップする必要があります。実際問題として、これは非常に簡単な傾向があります。
最も一般的なケースでは、デリゲートやラムダ式などを使用する場合、この問題は特定のプログラムが終了するかどうかを確認することと同等であるという直感があります (停止問題)。答え。
あなたの本当の目標が、変更によって何かが壊れたかどうかをすばやくテストできるようにすることである場合は、次のことをお勧めします。
VS2010 の「View Call Hierarchy」または ReSharpers の「ReSharper -> Inspect -> Incoming calls」を使用できます。ReSharper から結果をエクスポートすることもできます。
目標を達成するために自動化を使用したい場合、つまりこれは 1 回限りのものではなく、ビルド プロセスに統合したい場合は、独自のソリューションを構築することをお勧めします。アセンブリで Reflection または Mono.Cecil を使用して、自分で呼び出し階層をたどることができます。ただし、すべてのアセンブリに対して完全な呼び出し階層ツリーを作成する必要があるため、これにはかなりの時間がかかる可能性があります。もう 1 つの可能性は、Visual Studio または ReSharper プラグインを作成して、ソース コードから作成されたオブジェクト モデルにアクセスできるようにすることです。
基本的に、私が言いたいのは、自動化によって目標を達成するための現在既存の方法を知らないということです。独自のソリューションを作成するのは楽しいですが、開発または実行するときにトリッキーで時間がかかる可能性があります。