24

通常、コードベースと関連する単体テストをどのように分離していますか? 単体テスト用に別のプロジェクトを作成する人を知っていますが、個人的には混乱し保守が難しいと感じています。一方、1 つのプロジェクトでコードとそのテストを混同すると、単体テスト フレームワーク (NUnit、MbUnit など) に関連するバイナリと独自のバイナリが並んでしまいます。

これはデバッグには問題ありませんが、リリース バージョンをビルドすると、コードで単体テスト フレームワークを参照する必要がなくなります。

私が見つけた 1 つの解決策は、すべての単体テストを #if DEBUG -- #endif ディレクティブで囲むことです。コードが単体テスト アセンブリを参照していない場合、コンパイラはコンパイル済みコード内の参照を省略できます。

同様の目標を達成するための他の (おそらくより快適な) オプションはありますか?

4

13 に答える 13

42

テストを別のプロジェクトに分離することを強くお勧めします。私の意見では、それが唯一の方法です。

はい、Garyが言うように、クラスの内部で遊ぶのではなく、パブリック メソッドを介して動作をテストすることも強制されます。

于 2008-09-17T10:24:09.683 に答える
21

他の人が指摘しているように、(通常のプロジェクトごとに) 個別のテスト プロジェクトを作成するのが良い方法です。私は通常、名前空間をミラーリングし、名前に「test」を追加して、通常のクラスごとにテスト クラスを作成します。別のプロジェクトでテスト クラスとメソッドを自動的に生成できる Visual Studio Team System がある場合、これは IDE で直接サポートされます。

「内部」アクセサーを使用してクラスとメソッドをテストする場合に覚えておくべきことの 1 つは、テストする各プロジェクトの AssemblyInfo.cs ファイルに次の行を追加することです。

[assembly: InternalsVisibleTo("UnitTestProjectName")]
于 2008-09-17T10:37:37.437 に答える
10

v2 以降の .Net フレームワークには、別のアセンブリがアクセスできるようにする InternalsVisibleTo 属性を使用してアセンブリをマークできる便利な機能があります。
一種のアセンブリ トンネリング フィーチャ。

于 2008-09-17T10:37:32.633 に答える
9

ファイル内でコンパイラ ディレクティブを使用したり、別のプロジェクトを作成したりする代わりに、プロジェクトに追加の .cs ファイルを作成するだけです。

プロジェクト ファイル自体にいくつかの魔法を使用すると、次のように指定できます。

  1. nunit.framework DLL は、デバッグ ビルドでのみ参照されます。
  2. テスト ファイルはデバッグ ビルドにのみ含まれます

.csproj の抜粋の例:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

   ...

   <Reference Include="nunit.framework" Condition=" '$(Configuration)'=='Debug' ">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\debug\nunit.framework.dll</HintPath>
   </Reference>

   ...

   <Compile Include="Test\ClassTest.cs" Condition=" '$(Configuration)'=='Debug' " />

   ...
</Project>
于 2008-09-23T13:43:51.207 に答える
3

単体テスト用に別のプロジェクトを作成することをお勧めします (さらに、統合テスト、機能テストなどにはさらに多くのプロジェクトを作成することをお勧めします)。同じプロジェクトにコードとテストを混在させてみましたが、それらを別々のプロジェクトに分離するよりも保守性がはるかに低いことがわかりました。

並列の名前空間を維持し、テストに適切な命名規則 (MyClass や MyClassTest など) を使用すると、コードベースを維持しやすくなります。

于 2008-09-17T10:32:20.257 に答える
2

テストを別のプロジェクトに入れましたが、同じソリューションに入れました。確かに、大きなソリューションでは多くのプロジェクトが存在する可能性がありますが、ソリューション エクスプローラーはそれらを分離するのに十分であり、すべてに適切な名前を付ければ、それは問題ではないと思います。

于 2008-09-17T11:31:29.523 に答える
2

テストが別のプロジェクトにある限り、テストはコードベースを参照できますが、コードベースがテストを参照する必要はありません。2 つのプロジェクトを維持することの何が混乱を招くのでしょうか? 組織のために同じソリューションにそれらを保持できます。

もちろん、複雑な部分は、企業がソリューションに 55 のプロジェクトを持ち、そのうちの 60% がテストである場合です。自分をラッキーだと思ってください。

于 2008-09-17T10:45:40.537 に答える
2

まだ考慮されていないことの 1 つは、2005 年より前のバージョンの VisualStudio では、EXE アセンブリ プロジェクトを他のプロジェクトから参照することが許可されていなかったことです。したがって、VS.NET でレガシー プロジェクトに取り組んでいる場合、オプションは次のようになります。

  • 単体テストを同じプロジェクトに配置し、条件付きコンパイルを使用してリリース ビルドから除外します。
  • すべてをdllアセンブリに移動して、exeが単なるエントリポイントになるようにします。
  • テキスト エディターでプロジェクト ファイルをハッキングして、IDE を回避します。

3 つの条件付きコンパイルのうち、最もエラーが発生しにくいのは条件付きコンパイルです。

于 2009-04-13T15:19:28.883 に答える
1

#if（DEBUG）タグでクリーンな「リリース」バージョンが許可されている場合、テスト用に別のプロジェクトが必要になるのはなぜですか。nunit LibarryA / Bの例（ええ、私はその例を知っています）がこれを行います。現在、シナリオに取り組んでいます。別のプロジェクトを使用していましたが、これにより生産性が向上する可能性があります。まだハミンとハーウィン。

于 2009-07-08T15:12:05.953 に答える
1

私は常に単体テストを別のプロジェクトに保持しているので、独自のアセンブリにコンパイルされます。

于 2008-09-17T10:24:38.280 に答える
1

各プロジェクトには、テストを含む対応する .Test プロジェクトがあります。

たとえば、"Acme.BillingSystem.Utils" という名前のアセンブリには、"Acme.BillingSystem.Utils.Test" という名前のテスト アセンブリがあります。

その dll を出荷しないことにより、製品の出荷バージョンから除外します。

于 2008-09-17T10:27:20.067 に答える
0

私は常に、個別にコンパイルされた個別のAcme.Stuff.Testプロジェクトを作成します。

逆の議論は次のとおりです。なぜあなたはテストを取りたいのですか？テストを提供してみませんか？テストランナーと一緒にテストを提供する場合、製品とともにある程度の受け入れテストとセルフテストが提供されます。

この議論を何度か聞いて考えましたが、個人的には別のプロジェクトでテストを続けています。

于 2008-09-17T11:20:13.123 に答える
0

私は、テストを本番コードから分離する必要があるという点で、他のすべての人に完全に同意します。ただし、そうしないと主張する場合は、TEST という条件付きコンパイル定数を定義し、すべての単体テスト クラスを

#if TEST
#endif

最初に、テスト コードが運用シナリオでコンパイルされないことを確認します。それが完了したら、実稼働環境からテスト dll を除外するか、より良い方法として (ただし、より高度なメンテナンス)、テスト dll への参照なしでコンパイルする実稼働用の NAnt または MSBuild を作成できます。

于 2008-09-17T10:42:54.600 に答える