ユニットテストのためのNUnitとVisual Studio 2008のテストプロジェクトの比較 [閉まっている]


254

私は仕事で新しいプロジェクトを開始するつもりであり、ユニットテストに入りたいと思っています。VS 2008、C#、およびASP.NET MVCのものを使用します。NUnitまたはVS2008に組み込まれているテストプロジェクトを使用することを検討していますが、他の提案を調査することもできます。1つのシステムが他のシステムよりも優れているか、またはおそらく他のシステムよりも使用/理解が容易ですか?このプロジェクトを、今後の開発努力の「ベストプラクティス」の一種として設定してもらいたいと思っています。

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

回答:


99

Daok VS2008テストプロジェクトの名前のすべてのプロのは、ここでNUnitののプロのです。

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

19
mstest.exeを使用して、IDEの外部でMSTestテストを実行することはできませんか?
フィリップウェルズ

13
モックフレームワークを備えたNunitはあまりメリットがありません。私は、LINQ式ツリーを活用する斬新なアプローチを使用するMoqフレームワークでVS 2008単体テストプロジェクトを使用してきました。code.google.com/ p
DSO

5
とにかく、私にとってNunitのもう1つの利点は、Resharperが非常に優れたUIをラップしていることです。これは、VSテストコンポーネントよりもはるかに高速です。失敗したテストのスタックトレースをコードにハイパーリンクします。
Jeff Putz

7
ユニットテストは、VS 2008のプロフェッショナル版に含まれている
user179700

3
@Jeff Putz:Resharperは、テストプロジェクトの外でも、Visual Studioの単体テストを実行できます。
ポールルアン

64

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

 #if!NUNIT
  Microsoft.VisualStudio.TestTools.UnitTestingを使用します。
 #そうしないと
  NUnit.Frameworkを使用します。
  TestClass = NUnit.Framework.TestFixtureAttribute;を使用します。
  TestMethod = NUnit.Framework.TestAttribute;を使用します。
  TestInitialize = NUnit.Framework.SetUpAttribute;を使用します。
  TestCleanup = NUnit.Framework.TearDownAttribute;を使用します。
  TestContext = System.String;を使用します。
  DeploymentItem = NUnit.Framework.DescriptionAttribute;を使用します。
 #endif

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


12
NUnitの構文はMSTestよりも豊富であるため、私はこれに反対票を投じました。つまり、MSTest-> NUnitから移動できますが、特に注意しない限り、その逆はできません。歴史は私たちの少なくとも一人がそうではないことを示しています。
トーマス・アイド2009

2
私はトーマスに同意します。これは、最も基本的なassertステートメントを使用していることを前提として機能しますが、NUnit制約モデルは非常に強力であり、MSTestよりもNUnitを選択するのに十分な理由があります。
マーク・

私は、このアプローチはEntLibテストのmsパターンと実践グループによって採用されていると思います。
robi-y

1
@Dan Neelyあなたがプライベートをテストしているなら、あなたはそれを間違っています:(
JDPeckham

2
@JDPeckhamツールで行うべき/すべきでないことの慣例が重要ではないと言っているわけではありませんが、結局のところ、仕事を成し遂げることが最も重要です。ツールベンダーがハンマーを販売していないので、それが手斧の裏側で釘を打つことを意味するならば、手斧の製造業者は憤慨して生きていかなければなりません。
ダンであるいじることでファイアーライト

34

VS2008ビルトインユニットテストフレームワークの利点/変更

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

4
Microsoftのテストに対する見方については、Standardバージョンではなく、Professional以上のみであることを示していると思います。
J Wynia 2009年

同意します。標準以上に見たいと思います。エクスプレス版では初心者にはやり過ぎです。
Simara 2009年

1
@J Wynia:専門家以上にのみ含めるという彼らの決定を読んで、テストに対する彼らの見解について何かを言うのはあまりにも多くのことを読んでいます。それは哲学的な決定ではなく、ビジネス上の決定である可能性が高いです。
ジェイソン

@Simaraテストは、開発ライフサイクルに固有のものである必要があります。エクスプレス版で提供する必要があります。
eastender 2013

33

私は2年間NUnitを使用しています。すべては問題ありませんが、VSのユニットシステムは、Guiの内部にあり、めちゃくちゃにせずにプライベート関数のテストをより簡単に行うことができるので、かなり良いと言わざるを得ません。また、VSのユニットテストでは、NUnitだけでは実行できないカバーやその他のことを実行できます。


44
プライベートには触れないでください。冗談はさておき、1つの考え方では、テストに必要なのは公開メソッドだけだということです。すべてのパブリックメソッドを呼び出すと、すべてのプライベートメソッドが呼び出されます。プライベートメソッドがパブリックメソッドを介して呼び出されていない場合、プライベートメソッドは冗長です。
Lieven Keersmaekers 2009年

7
@Lieven:公衆を介してプライベートをテストしている場合、実際には単体テストではなく統合テストを行っています。(もちろん、私はTDDの熱狂的ファンではないので、たぶん一般の人々をテストするだけです...でも、戦いを始める手助けをしたい気がします)
マシューホワイト

11
@マシュー、統合テストは2つ以上のユニットを一緒にテストしています。プライベートメソッドのテストはカプセル化の(巨大な)違反にすぎず、実装が変更されるたびに変更する必要がある脆弱な単体テストにつながる可能性があります。
Omer Rauchwerger、2009

3
また、コンパイラディレクティブで[assembly:InternalsVisibleTo(...)]を使用して、RTMビルドを作成するときにそれを削除することもできます。
Iain Galloway

1
私は常にプライベートに触れています:)プライベートメンバーを具体的にテストすることには、多くの複雑な設定を必要とする呼び出し元をテストすることによるオーバーヘッドを回避する価値があると思います。
クラッカージャック2010年

14

Visual Studioのテストフレームワークのわずかな不満の1つは、プロジェクトディレクトリがいっぱいになる傾向がある多くのテスト実行ファイルを作成することです-これはそれほど大きな問題ではありません。

また、TestDriven.NETなどのプラグインがない場合、組み込みのMicrosoft VSテストフレームワークとは異なり、Visual Studio環境内でNUnit(またはMbUnit、xUnitなど)の単体テストをデバッグできません。


3
あなたは、Visual Studio 2005内のテストNUnitのをデバッグすることができます
ジェイソン・ショート

xunitをデバッグすることもできますが、それを設定する方法(プロパティページ)は明白ではありません
annakata

1
grimusが言っているように、実行中のNUnitプロセスにデバッガーをアタッチすることで、NUnitを簡単にデバッグできます。ここには実際の欠点はありません。
Anne Schuessler、2010年

1:VS設定で構成可能なテストの数-1に設定しました。2:上記のコメントに同意します-可能ですが扱いにくいです。3:全体的に、組み込みのVSテスト環境を好みます。
RaoulRubin 2013

14

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

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

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


R#のGallioプラグインを使用すると、MSTestも実行できます。
Kjetil Klaussen、

CodeRushは、コード内のテストにアイコンを配置して、1つのテスト、またはクラスまたは名前空間内のすべてのテストを実行できるようにします。ここを参照してください: community.devexpress.com/blogs/markmiller/archive/2009/11/16/...
ライアン・ランディ

ResharperはMSTestテストも実行します。
JDPeckham 2011年


11

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

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

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


11

私は両方を使用していくつかのTDDを実行し、(多分私は少しばかげているかもしれません)nUnitは私にとってはるかに高速で簡単に使用できるようです。そして私がたくさん言うとき、私はたくさんを意味します。

MS Testには、いたるところに属性が多すぎます。実際のテストを実行するコードは、あちこちで読み取れる小さな行です。大きな混乱。nUnitでは、テストを実行するコードが属性を支配するだけです。

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

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

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

nUnitについては、1つ読んだ。そして私は同じ日にTDDをしていました。楽しみで。

ちなみに、私は通常マイクロソフト製品が大好きです。Visual Studioは、開発者が購入できる最高のツールですが、Visual Studio Team SystemでのTDDと作業項目の管理は、本当にひどいものです。

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


9

「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

または他の変換... :-)ここでの使用は、コンパイラの単なるエイリアスです。


1
ここで何を言っているのかわかりません。
PositiveGuy

フィクスチャレベルのセットアップ/ティアダウンがありません:(または、彼らはctorとdtorを使用すると想定していますか?
JDPeckham

9

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


8

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

同じテストを何度も書くのは嫌だった。特に、テストメソッドが数百のテストに簡単に実行できる大規模なプロジェクトでは。

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



7

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つの異なる開発チームをメリットに変えてきました。


6

私の知る限り、最近では.NETを使用した単体テストに利用できる4つのフレームワークがあります。

  • NUnit
  • MbUnit
  • MSTest
  • xUnit

NUnitは常に先頭に立っていましたが、ギャップは昨年かそこらで閉じています。私はまだ自分自身がNUnitを好みます。特に、しばらく前に流暢なインターフェイスを追加して、テストを非常に読みやすくしました。

単体テストを始めたばかりの場合は、それほど大きな違いはないでしょう。速度が上がると、ニーズに最適なフレームワークを判断するのに適した状態になります。


6

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


3
実際にVisual Studioをだますことができます。手動でプロジェクトファイルを編集し、テストプロジェクトの識別に使用するProjectTypeGuids値を追加します:< ProjectTypeGuids> {3AC096D0-A1C2-E12C-1390-A8335801FDAB}; {FAE04EC0-301F-11D3- BF4B-00C04F79EFBC}< / ProjectTypeGuids>
Paul Ruane

5

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

とはいえ、Microsoftのラベルが付いていないもの、特にOSSコードを使用することに非常に消極的である企業がいくつかあります。したがって、公式のMSテストフレームワークを持つことは、これらの企業がテストを受ける必要がある動機になる可能性があります。正直に言って、どのツールを使用するかではなく、重要なのはテストです(そして上記のTuomas Hietanenのコードを使用すれば、テストフレームワークをほぼ交換可能にすることができます)。


NUnitの制約構文は大好きですがSetUpTearDown属性と属性については、こちらをお読みください。jamesnewkirk.typepad.com
Nobody

4

コードコントラクトシステムの .NET 4.0でのリリースと静的チェッカーの可用性により、理論的にはより少ないテストケースを書く必要があり、Pexのようなツールがそれらのケースを特定するのに役立ちます。これを手元のディスカッションに関連付けてください。契約がテールを​​カバーしているためにユニットテストの実行を減らす必要がある場合は、管理への依存度が1つ少ないため、組み込みの部分を使用しないでください。最近、私は単純さについてすべてです。:-)

以下も参照してください。


3

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

  • 維持する必要がある共有「テスト」ファイル(無意味)
  • テストリストは複数の開発者/ VCSとの競合を引き起こします
  • 統合されたUIが不十分-セットアップがわかりにくく、面倒なテスト選択
  • 良い外部ランナーはありません

警告-aspxサイトをテストしている場合は、必ず MSを使用します-単独で開発している場合も、MSは問題ありません-スキルが限られていて、NUnitを構成できなかった場合:)

テストを記述してNUnitGUIまたは他のフロントエンドの1つを起動する方がはるかに簡単です(testDrivenははるかにはるかに高額です)。コマンドラインバージョンを使用したデバッグのセットアップも非常に簡単です。


現在、Resharperを使用してMSテストを実行しているので、あまり気にしません。ここではCodeRush + RefactorProを使用していますが、ここでは使用しません。多分彼らは今もMSテストのためのまともなランナーを持っています。
Andrew Backer
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.