使用できるアプローチがいくつかあります。1 つは、ファイルを埋め込みリソースとしてデプロイし、フィクスチャ/テスト クラスの初期化メソッドでテスト実行時にそれらを抽出することです。このアプローチは非常に信頼性が高く (つまり、テスト アセンブリが実行される場所は問題ではありません)、少し複雑です (ファイルを埋め込みリソースとしてマークする必要があり、ファイルを埋め込むときに使用される命名規則について学ぶ必要があります)。また、Assembly.GetManifestResourceStream()) に慣れる必要があります。
別の方法として、"loose files" (つまり、埋め込まれていないファイル) を使用することもできます。このアプローチでは、ファイルを「常にコピー」または「新しい場合はコピー」としてマークするだけです。これにより、ファイルがテスト アセンブリのビルド出力ディレクトリにコピーされます。NUnit を使用している場合は、そこで終了できます。MSTest (Visual Studio に付属) を使用している場合は、テスト クラスまたはメソッドに [DeploymentItem] 属性を追加する必要があります。
[DeploymentItem("MyFile.xml"[, "someoptionalsubfolder"])]
public void MyTest()
{
...
}
上記の両方で、リソースを追跡できるように、リソースのフォルダー構造/命名規則を採用することをお勧めします。以下のようなものがうまくいきました。これは、ASP.NET MVC が使用し、非常にうまく機能するフォルダー構造から抜粋したものです。このアプローチでは、「共有」リソース (つまり、アセンブリまたはテスト クラス レベルで一連のテストに対して一定のもの) を持つことができますが、各テスト セットまたは各テストでさえ、リソースの独自の特定のバージョンを持つことができます (たとえば、「無効なデータ」応答のテストやエッジケース シナリオのテストなど):
+-Resources
+-Shared
- SomeGlobalResource.xml
+-TestClass1
+-Shared
- MockData.xml
+-TestCase1
- SpecialVersionofMockData.xml
+-TestCase2
- MockDataMissingRequiredInformation.xml
+-TestCase3
- EtCetera.xml
+-...
+-TestClass2
+-Shared
+-TestCase1
+-TestCase2
+-...
+-TestClass3
...
ところで、このアプローチに従うと、MSTest で DeploymentItem 属性を使用する方法が大幅に簡素化されます。気が狂って各リソース ファイルの属性を維持する代わりに、リソース フォルダー ツリー全体をコピーする単一のディレクティブをクラスに配置するだけです。
[DeploymentItem("Resources\\", "Resources")]
[TestClass]
public class MyTestClass()
{
...
}
編集: テスト コンテンツへのパスを管理する必要があることを指摘しておきます。NUnit も MSTest も、現在実行中のテストに基づいてパスを自動生成するツールを提供していません。これは、テスト コードをコピー アンド ペーストするときに、正しいパスを維持することに注意する必要があることを意味します。