NUnit と MSTest とでのテストコードの共有は難しい? - 周辺ファイルの配置

前回の投稿で書いた、NUnit と MSTest とでのテストコードの共有が、じつは難しいのではないかとの件の続き。

例えば、指定したフォルダ以下のファイルとサブフォルダの一覧を Dictionary で返すようなクラスライブラリの単体テストコードを作成するものとする。

このようなケースでは、このテスト対象のクラスライブラリに走査させるテスト用のファイルとサブフォルダが必要であろう。

このような、テストを行うために必要な外部ファイルを、「周辺ファイル」と呼ぶことにする（「周辺ファイル」という用語は MSTest 関連のドキュメントから）。

で、NUnit と MSTest とでは、この、周辺ファイルの取り扱い方が異なってくるのだ。

NUnit

ポイントは、テストに必要な周辺ファイルを、テストプロジェクトの出力フォルダ(bin\Debug)に配置することである。

NUnit のテストランナーでの実行の際、このテストプロジェクト出力フォルダがアプリケーションドメインのベースディレクトリになるので、テストコード上からは、AppDomain.CurrentDomain.BaseDirectory でアクセスできる。

周辺ファイルの配置方法だが、まず、周辺ファイル原本はテストプロジェクトフォルダ直下に配置し、プロジェクトに含めておく。
ソリューションエクスプローラ上からこれら周辺ファイルのプロパティを開いて、「出力ディレクトリにコピー」=「常にコピー」と設定しておけば、ビルドのたびに、周辺ファイル原本が出力フォルダにコピーされるようになる。

ただし、この方法では、空のフォルダを出力フォルダ以下へコピーすることができない。
「フォルダ内のファイルの本数を数えて返す」プログラムのテストを行いたい場合などに、「ファイルがひとつもないフォルダ」もテスト対象としたいので、これでは困る。

そんなときは、
プロジェクトのプロパティ→ビルドイベント→ビルド後に実行するコマンドライン
で、xcopy などのシェルコマンドを列記することで解決できる（xcopyなら /E スイッチを付けておくことで、空のフォルダもコピーできる）。
「ビルド後に実行するコマンドライン」では、$(ProjectDir) や $(TargetDir) などのマクロが使えるので、これらマクロを使用することで、テストプロジェクトフォルダ直下の周辺ファイル原本を出力フォルダへコピーすることができるようになる。


MSTest

さて、MSTest では、Visual Studio 2008 上からの実行時、アプリケーションドメインのベースディレクトリは Visual Studio IDE のフォルダになる（もうこの時点で、NUnit の場合とは事情が異なる）。

また、MSTest ではテストを実行する環境が、ソリューションのあるフォルダ\TestResults\実行構成スキームフォルダ（"テストフォルダ"と呼ぶらしい） にテスト実行のたびに作成され、累々と結果が蓄積される。
（蓄積される本数は、Visual Studio 2008 のオプション設定[ツール(T)]-[オプション(O)...] から、[テストツール]-[テストの実行] 内の[古いテスト結果の最大数(L)]で指定できる）

このテストフォルダを、テストコード上から参照するにはどうするかというと、MSTest 用のテストクラスをテンプレートから作成した際にはじめから記述されている、TextContext オブジェクトに問い合わせる。
どうやら、MSTest では、テストクラスをインスタンス化する際に、そのテストクラスオブジェクトの TestContext プロパティに、TestContext オブジェクトを挿入してくるようだ。
よって、各テストメソッド中では、this.TestContext.TestDir プロパティを参照することで、テストフォルダのパスを取得できる。
NUnit では AppDomain.CurrentDomain.BaseDirectory を利用していたが、MSTest では TestContext オブジェクトを利用することになる。
この時点で、NUnit と MSTest とでのテストコードの共有は困難に思える。

で、テストに必要な周辺ファイルの配置だが、こういう事情なので、NUnit の場合のように、出力フォルダに配置しても意味がない。
MSTest では、Solution Items として追加されるテスト実行構成（*.testrunconfig）を編集することで、周辺ファイルの配置を行う。
ソリューションエクスプローラからテスト実行構成（*.testrunconfig）を開くと、テスト実行構成編集用のダイアログが開く。
このダイアログに「配置」のカテゴリがあるので、ここに周辺ファイルを登録しておくとよい。
こうして登録されたファイルは、テスト実行のたびに、テストフォルダ直下の Out フォルダ以下にコピーされる。
なお、この Out フォルダのことを "テスト配置フォルダ" と呼ぶ模様。テスト配置フォルダへのパスは、テストコード中からは、TestContext オブジェクトの TestDeploymentDir プロパティで取得できる。

ところが、やっぱり、テスト実行構成の「配置」での周辺ファイルコピーでは、空のフォルダはコピーされない。
このような場合は、テスト実行構成編集ダイアログの「セットアップおよび後処理用のスクリプト」カテゴリを使う。
周辺ファイルをテスト配置フォルダにコピーするバッチファイルを作成し、テスト実行構成編集ダイアログ-「セットアップおよび後処理用のスクリプト」カテゴリ-「セットアップスクリプト」の欄に、このバッチファイルへのパスを指定する。
こうすると、テスト実行のたびに、このバッチファイルが実行される。
このバッチファイル中で、周辺ファイルのテスト配置フォルダへのコピーを行うコマンドを書けばよい。

ちょっとここで落とし穴。
テスト実行構成編集ダイアログの「...」ボタンを押してファイルダイアログを使ってこのバッチファイルを選択すると、このバッチファイルへのフルパス(絶対パス)で格納されてしまうのだ。
絶対パスが必ずしも悪いとは言えないが、開発チーム各位で開発用のドライブ・フォルダ構成が一致していなかったり、ソリューションの物理配置を変更したくなった場合にはこれでは都合悪い。
幸い、実際には、ソリューションフォルダからの相対パスで指定できるので、".\TestProject\SetUp.cmd" などと手作業で指定しておくとよい。

さて、このバッチファイル実行時には、以下の環境変数が使えるようになる。
TestDeploymentDir - テスト配置フォルダのフルパス
TestDir - テストフォルダのフルパス
TestLogsDir - (本投稿では触れていないが)テストログフォルダのフルパス

ここでもうひとつ落とし穴。
周辺ファイル原本へのファイルパスを取得するための環境変数はないのだ。
また、バッチファイル実行時のカレントフォルダはテスト配置フォルダとなっているので、カレントフォルダを基点として下位フォルダをたどることでは、テストプロジェクトフォルダに辿り着けない。
仕方がないので、環境変数 TestDir が指しているフォルダから2階層上のフォルダ（%TestDir%\..\..）を手繰ることでソリューションのフォルダであるはず、としてテストプロジェクトのフォルダを決定しコピーを行うバッチとした。

ということで、まとめ

周辺ファイルをテスト環境に配置するための手法が、NUnit と MSTest とで異なるのは、まぁ、まだ仕方がない。
というか、とりあえず MSTest 用に環境つくっておいて、後日、NUnit でも動かしたいとなったら、そのときに、NUnit 用にビルドイベントのバッチファイルを書けばよい。

しかしながら、テストコード中、周辺ファイルがあるフォルダパスの入手方法が、NUnit では AppDomain.CurrentDomain.BaseDirectory を参照、MSTest ではテストクラスの TestContext プロパティ参照というのはちょっとやっかいだ。

この件も、条件コンパイルなどでうまいこと回避できるものだろうか?
MSTest での周辺ファイルの配置などで苦労したので、今回はここまで...