web-dev-qa-db-ja.com

NUnit対Visual Studio 2008の単体テストのテストプロジェクト？

私は職場で新しいプロジェクトを立ち上げ、単体テストを始めたいと思っています。 VS 2008、C＃、およびASP.NET MVCを使用します。 NUnitまたはVS2008に組み込まれているテストプロジェクトの使用を検討していますが、他の提案を調査することもできます。 1つのシステムが他のシステムより優れているか、おそらく他のシステムよりも使用/理解しやすいでしょうか？このプロジェクトを、今後の開発努力の一種の「ベストプラクティス」として設定することを検討しています。

助けと提案をありがとう！

c#asp.net-mvcvisual-studio-2008unit-testingnunit
252
Ryan Skarin

Daok VS2008テストプロジェクトのすべてのプロに名前を付けました。ここにNUnitのプロを示します。

  • NUnitにはモックフレームワークがあります。
  • NUnitはIDEの外部で実行できます。これは、CC.Netなどの非MSビルドサーバーでテストを実行する場合に便利です。
  • NUnitには、Visual Studioよりも多くのバージョンがあります。新しいバージョンを何年も待つ必要はありません。また、新しい機能を取得するためにIDEの新しいバージョンをインストールする必要もありません。
  • 行テストなど、NUnit用に開発されている拡張機能があります。
  • Visual Studioのテストは、何らかの理由で起動に時間がかかります。これは2008年には改善されましたが、それでも私の好みには遅すぎます。テストをすばやく実行して、何かを壊していないかどうかを確認するには、時間がかかりすぎる可能性があります。 IDEからテストを実行するTestdriven.NetなどのNUnitは、実際にははるかに高速です。特に、単一のテストを実行する場合。
    Kjetil Klaussenによると、これはVisual Studioのテストランナーが原因で、TestDriven.NetでMSTestテストを実行すると、MSTestのパフォーマンスがNUnitに匹敵します。
98
Mendelt

単体テストフレームワークは、実際にはそれほど重要ではありません。テストクラスを個別のプロジェクトファイルと条件付きコンパイル（VS-> NUnitなど）で変換できるためです。

 #if！NUNIT 
 Microsoft.VisualStudio.TestTools.UnitTestingを使用; 
 #else 
 NUnit.Frameworkを使用; 
 using TestClass = NUnit。 Framework.TestFixtureAttribute; 
 TestMethod = NUnit.Framework.TestAttribute; 
 using TestInitialize = NUnit.Framework.SetUpAttribute; 
 using TestCleanup = NUnit.Framework.TearDownAttribute; 
を使用してTestContext = System.String; 
 using DeploymentItem = NUnit.Framework.DescriptionAttribute; 
 #endif

TestDriven.Netプラグインは素晴らしく、それほど高価ではありません...プレーンなVS2008のみで、テストクラスまたはテストリストからテストを見つける必要があります。 TestDriven.Netを使用すると、テストするクラスから直接テストを実行できます。結局のところ、単体テストは保守が容易で、開発者の近くにあるべきです。

64
Tuomas Hietanen

VS2008組み込みユニットテストフレームワークの利点/変更

  1. 2008バージョンは現在、プロフェッショナルエディションで利用可能です（VSの高価なバージョンが必要になる前、これは開発者ユニットテスト専用です）。多くの開発者は、オープン/外部テストフレームワークのみを選択できました。
  2. 単一の会社がサポートする組み込みAPI。
  3. 同じツールを使用してテストを実行および作成します（コマンドラインを使用してMSTestを実行することもできます）。
  4. シンプルなデザイン（Mockフレームワークは認められていませんが、これは多くのプログラマーにとって素晴らしい出発点です）
  5. 長期サポートが付与されました（nDocに何が起こったのかを今でも覚えています。5年後にサポートされない可能性のあるテストフレームワークにはコミットしたくありませんが、nUnitは素晴らしいフレームワークだと考えています。）
  6. チームファンデーションサーバーをバックエンドとして使用する場合、失敗したテストデータを使用して簡単な方法で作業項目またはバグを作成できます。
34
Simara

NUnitを2年間使用しています。すべては問題ありませんが、VSのUnitシステムはGui内にあり、混乱することなくプライベート機能のテストをより簡単に実行できるため、かなりいいと言わざるを得ません。また、VSの単体テストでは、NUnitだけではできないカバーやその他のことを行うことができます。

33
Patrick Desjardins

少しトピックから外れていますが、NUnitを使用する場合は、 ReSharper を使用することをお勧めします。VSUIにいくつかのボタンを追加し、IDE内からのテストの実行とデバッグをはるかに簡単にします。

このレビューは少し古いですが、これについてさらに詳しく説明しています。

http://codebetter.com/blogs/paul.laudeman/archive/2006/08/15/Using-ReSharper-as-an-essential-part-of-your-TDD-toolkit.aspx

14
Richard Everett

Visual Studioのテストフレームワークのやや面倒な点の1つは、プロジェクトディレクトリが乱雑になる傾向がある多くのテスト実行ファイルが作成されることです-これはそれほど大したことではありません。

また、TestDriven.NETなどのプラグインがない場合、組み込みのMicrosoft VSテストフレームワークと同様に、Visual Studio環境内でNUnit（またはMbUnit、xUnitなど）ユニットテストをデバッグすることはできません。

14
Tarsier

NUnitを介したVSユニットテストの私の主な機能は、VSテストの作成が、プライベートメンバーアクセス用に生成されたコードの束を挿入する傾向があることです。

プライベートメソッドをテストしたい人もいれば、そうでない人もいますが、これは別のトピックです。

私が懸念しているのは、ユニットテストを作成するとき、それらを非常に制御する必要があるため、テストする内容とテスト方法を正確に把握していることです。自動生成されたコードがある場合、その所有権の一部を失います。

11
Ian Suttle

私は両方を使用してTDDをいくつか実行しました（多分私は少し馬鹿だ）nUnitは私にとってはるかに高速で簡単に使用できるようです。そして、私がたくさん言うとき、私は多くのことを意味します。

MS Testでは、あらゆる場所に属性が多すぎます-実際のテストを行うコードは、あちこちで読むことができる小さな行です。大きな混乱。 nUnitでは、テストを実行するコードが属性を支配します。

また、nUnitでは、実行するテスト（1つだけ、クラスをカバーするすべてのテスト、アセンブリ、ソリューション）をクリックするだけです。ワンクリック。そして、窓は明確で大きくなっています。明確な緑と赤のライトが点灯します。あなたは本当に一目で何が起こるか知っています。

VSTSでは、テストリストは画面の下部に詰まっていて、小さくて見苦しいです。何が起こったのかを知るには、二度見なければなりません。また、テストを1つだけ実行することはできません（まあ、まだわかりませんでした！）。

しかし、私は間違っているかもしれません-「VSTSを使用して簡単なTDDを行う方法」に関する21のブログ投稿を読んだだけです。私はもっ​​と読むべきでした、あなたは正しいです。

NUnitについては、1つを読みます。そして、私は同じ日にTDDをしていました。楽しみにして。

ところで、私は通常マイクロソフト製品が大好きです。 Visual Studioは開発者が購入できる最高のツールですが、Visual Studio Team SystemのTDDとワークアイテムの管理は本当に残念です。

ではごきげんよう。シルヴァン。

11
Sylvain Rodrigue

XUnitは、グリーンフィールドプロジェクトのもう1つの可能性です。おそらくより直感的な構文を持っていますが、他のフレームワークとは実際には互換性がありません。

http://www.codeplex.com/xunit

11
Ben Fulton

まず、間違ったステートメントを修正します。コマンドラインを使用して、Visual Studioの外部でmsTestを実行できます。 TeamCityなどのいくつかのCIツールでは、NUnitのサポートが強化されています（msTestが一般的になると、おそらく変更されるでしょう）。私の現在のプロジェクトでは両方を使用していますが、唯一の大きな違いは、mstestは常に32ビットとして実行され、NUnitは32ビットまたは64ビットのテストとして実行され、コードが32/64依存のネイティブコードを使用する場合にのみ重要です。

9
Dror Helper

「NUnitファイル構造はVSTestよりも豊富です」というメッセージが表示されました...もちろん、NUnitファイル構造を好む場合は、このソリューションを他の方法で使用できます（NUnit-> VS）。

 #if !MSTEST
  using NUnit.Framework;
 #else
  using Microsoft.VisualStudio.TestTools.UnitTesting;
  using TestFixture = Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute;
  using Test = Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute;
  using SetUp = Microsoft.VisualStudio.TestTools.UnitTesting.TestInitializeAttribute;
  using TearDown = Microsoft.VisualStudio.TestTools.UnitTesting.TestCleanupAttribute;
 #endif

またはその他の変換... :-)ここで使用するのは、コンパイラの別名です。

9
Tuomas Hietanen

私はMSTestから始めましたが、1つの簡単な理由で切り替えました。 MSTestは、他のアセンブリからのテストメソッドの継承をサポートしていません。

同じテストを複数回書くという考えが嫌いでした。特に、テストメソッドが数百のテストに簡単に到達できる大規模プロジェクトで。

NUnitは私が必要とすることを正確に行います。 NUnitで不足しているのは、各テストの赤/緑のステータス（VSTSのような）を表示できるVisual Studioアドインだけです。

8
Th3Fix3r

MSTestまたはnUnitのいずれかを検討している場合は、mbUnitを確認することをお勧めします。私の理由は

  1. TestDriven.Netの互換性。 TestDriven.Net.ReRunWithDebuggerがキーボードの組み合わせにバインドされているビートはありません。
  2. Gallioフレームワーク。 Gallioは、nUnitsのようなテストランナーです。唯一の違いは、nUnit、msTest、xUnit、またはmbUnitでテストを記述してもかまいません。それらはすべて実行されます。
  3. NUnitとの互換性。 nUnitのすべての機能はmbUnitでサポートされています。属性を変更する必要はなく（それを確認する必要があります）、参照と使用方法だけを変更する必要があります。
  4. コレクションがアサートします。 mbUnitには、CollectionAssertクラスを含む、より多くのAssertケースがあります。基本的に、2つのコレクションが同じかどうかを確認するために独自のテストを記述する必要はありません。
  5. 組み合わせテスト。 2組のデータを提供し、データのすべての組み合わせのテストを取得できたらいいと思いませんか。 mbUnitにあります。

私はもともと[RowTest ....]機能のためにmbUnitを選択しましたが、戻る理由は1つも見つかりませんでした。すべてのアクティブなテストスイートをnUnitから移動しましたが、振り返ることはありませんでした。それ以来、2つの異なる開発チームを特典に変えました。

7
AlSki

。NETテストフレームワークアドバイス および 。NETユニットテストパッケージ？ 。

7
EfForEffort

VS組み込みのテストフレームワークは好きではありません。テストするプロジェクトの一部としてテストを行うのではなく、別のプロジェクトを作成する必要があるからです。

6
Gene Mitelman

MSTestは基本的にNUnitをわずかに作り直し、いくつかの新機能（フィクスチャとテストレベルだけでなく、アセンブリのセットアップと分解など）を備えており、いくつかのベストビット（新しい2.4制約構文など）が欠落しています。 NUnitはより成熟しており、他のベンダーからより多くのサポートを受けています。もちろん、常に無料であるため（MSTestは2008年のProfessionalバージョンになりましたが、それ以前はより高価なSKUでした）、ほとんどのALT.NETプロジェクトで使用されています。

そうは言っても、Microsoftのラベルが付いていないもの、特にOSSコードを使用することに非常に消極的な企業があります。したがって、公式のMSテストフレームワークを用意することは、これらの企業がテストを受ける必要がある動機かもしれません。正直なところ、重要なのはテストであり、使用するツールではありません（および Tuomas Hietanenのコード を使用すると、テストフレームワークをほぼ交換可能にできます）。

5
David Keaveny

.NET 4.0の Code Contractsシステム のリリースと staticチェッカー の可用性により、理論的にはより少ないテストケースを記述し、 Pex のようなツールは、これらのケースを識別するのに役立ちます。これを手近な議論に関連して、契約があなたの尻尾をカバーしているためにユニットテストでより少なくする必要があるなら、それは管理するための1つの少ない依存性であるので、先に進んでビルトインピースを使用してはどうですか？最近では、シンプルさがすべてです。 :-)

こちらもご覧ください：

4
Norman H

私はMSの小さなテストフレームワークを使用したいと思いますが、今のところはNUnitに固執しています。 MSの問題は一般に（私にとって）

  • 維持でなければならない共有「テスト」ファイル（無意味）
  • テストリストは、複数の開発者/ VCSと競合します
  • 統合されたUIが貧弱-わかりにくいセットアップ、面倒なテスト選択
  • 良い外部ランナーなし

警告-aspxサイトをテストしている場合、私は間違いなく MSを使用します-ソロを開発している場合、MSも大丈夫です-スキルが制限されていて、NUnitを構成できなかった場合:)

テストを書いて、NUnitGUIまたは他のフロントエンドの1つを起動する方がはるかに簡単です（testDrivenははるかに高すぎます）。コマンドラインバージョンでのデバッグのセットアップも非常に簡単です。

3
Andrew Backer