255

私は職場で新しいプロジェクトを開始する予定で、単体テストを開始したいと考えています。Visual Studio 2008、C#、および ASP.NET MVC を使用します。NUnit または Visual Studio 2008 に組み込まれているテスト プロジェクトのいずれかを使用することを検討していますが、他の提案を調査することもできます。あるシステムが他のシステムよりも優れているか、それとも他のシステムよりも使いやすく/理解しやすいか?

このプロジェクトを、今後の開発努力の一種の「ベスト プラクティス」として設定したいと考えています。

4

18 に答える 18

99

Daokは、VisualStudio2008テストプロジェクトのすべてのプロに名前を付けました。これがNUnitのプロです。

  • NUnitにはモックフレームワークがあります。
  • NUnitはIDEの外部で実行できます。これは、 CruiseControl.NETなどのMicrosoft以外のビルドサーバーでテストを実行する場合に役立ちます。
  • NUnitには、VisualStudioよりも多くのバージョンがあります。新しいバージョンを何年も待つ必要はありません。また、新しい機能を取得するためにIDEの新しいバージョンをインストールする必要はありません。
  • 行テストなど、NUnit用に開発されている拡張機能があります。
  • Visual Studioのテストは、何らかの理由で起動するのに長い時間がかかります。これはVisualStudio2008の方が優れていますが、それでも私の好みには遅すぎます。何かを壊していないかどうかを確認するためにテストをすばやく実行すると、時間がかかりすぎる可能性があります。Testdriven.Netのようなものを使用してIDEからテストを実行するNUnitは、実際にははるかに高速です。特に単一のテストを実行する場合。Kjetil Klaussenによると、これはVisualStudioのテストランナーが原因です。TestDriven.NetでMSTestテストを実行すると、MSTestのパフォーマンスがNUnitに匹敵します。
于 2008-09-18T14:33:41.713 に答える
64

個別のプロジェクト ファイルと条件付きコンパイル (このように、Visual Studio → 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 プラグインは素晴らしく、それほど高価ではありません... プレーンな Visual Studio 2008 だけでは、テスト クラスまたはテスト リストからテストを見つける必要があります。TestDriven.Netを使用すると、テストしているクラスから直接テストを実行できます。結局のところ、単体テストは保守が容易で、開発者の近くにある必要があります。

于 2008-09-18T14:59:22.447 に答える
34

Visual Studio 2008 組み込み単体テスト フレームワークの利点/変更点:

  1. 2008 バージョンは現在、プロフェッショナル エディション (Visual Studio の高価なバージョンが必要になる前であり、これは開発者のユニット テストのためだけのものです) で利用できるため、多くの開発者はオープン/外部テスト フレームワークしか選択できませんでした。
  2. 1社でサポートするビルトインAPI。
  3. 同じツールを使用して、テストを実行および作成します (コマンド ラインを使用して実行することもできますMSTest )。
  4. シンプルなデザイン (モック フレームワークなしで許可されますが、これは多くのプログラマーにとって優れた出発点です)。
  5. 長期サポートが付与されます ( NDocに何が起こったのかは今でも覚えています。5 年後にサポートされなくなる可能性のあるテスト フレームワークにコミットしたくはありませんが、NUnit は優れたフレームワークであると考えています)。
  6. Team Foundation Server をバックエンドとして使用している場合、失敗したテスト データを使用して作業項目またはバグを簡単な方法で作成できます。
于 2008-11-18T16:49:28.723 に答える
33

NUnit を 2 年間使用しています。すべて問題ありませんが、Visual Studio の単体テスト システムは非常に優れていると言わざるを得ません。なぜなら、それは GUI 内にあり、いじる必要なくプライベート関数のテストをより簡単に実行できるからです。

また、Visual Studio の単体テストでは、NUnit だけではできないカバーやその他の作業を行うことができます。

于 2008-09-18T14:13:30.530 に答える
14

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

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

ReSharper を TDD ツールキットの不可欠な部分として使用する

于 2008-11-28T11:28:50.987 に答える
14

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

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

于 2008-09-19T22:35:35.517 に答える
11

NUnitを介したVisualStudio単体テストでの私の主な目的は、Visual Studioテストの作成により、プライベートメンバーアクセス用に生成されたコードの束が挿入される傾向があることです。

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

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

于 2009-03-08T06:59:28.747 に答える
11

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

于 2008-09-18T19:46:57.437 に答える
11

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

MSTestでは、どこにでも属性が多すぎます。実際のテストを実行するコードは、あちこちで読むことができる小さな行です。大きな混乱。NUnitでは、テストを実行するコードが属性を支配するだけです。

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

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

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

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

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

于 2009-07-08T20:46:26.213 に答える
9

「NUnit ファイル構造は VSTest よりもリッチです」というメッセージが表示されました... もちろん、NUnit ファイル構造を好む場合は、このソリューションを別の方法で使用できます (NUnit → Visual Studio):

 #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

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

于 2009-02-13T18:53:46.640 に答える
9

最初に、間違ったステートメントを修正したいと思います。コマンド ラインを使用して、Visual Studio の外部で MSTest を実行できます。TeamCityなどのいくつかの CI ツールは NUnit をより適切にサポートしていますが (MSTest がより一般的になるにつれて変更される可能性があります)。

私の現在のプロジェクトでは、両方を使用していますが、唯一の大きな違いは、MSTest は常に 32 ビットとして実行され、NUnit は 32 ビットまたは 64 ビットのテストとして実行されるということです。これは、コードが 32/64 ビットに依存するネイティブ コードを使用する場合にのみ問題になります。

于 2008-09-19T20:25:49.103 に答える
8

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

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

NUnit はまさに私が必要とすることを行います。NUnit に欠けている唯一のものは、各テストの赤/緑のステータス ( VSTSなど) を表示できる Visual Studio アドインです。

于 2009-06-12T05:53:22.007 に答える
7

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

  1. TestDriven.Net との互換性。キーボードの組み合わせにバインドされた TestDriven.Net.ReRunWithDebugger に勝るものはありません。
  2. ガリオ フレームワーク。Gallio は、NUnit のようなテスト ランナーです。唯一の違いは、テストを NUnit 、 MSTestxUnit、または MbUnitで記述したかどうかを気にしないことです。それらはすべて実行されます。
  3. NUnit との互換性。NUnit のすべての機能は MbUnit でサポートされています。参照とusings.
  4. コレクションはアサートします。MbUnit には、CollectionAssert クラスを含む、より多くの Assert ケースがあります。基本的に、2 つのコレクションが同じかどうかを確認するために独自のテストを作成する必要はなくなりました。
  5. 組み合わせテスト。2 セットのデータを提供して、データのすべての組み合わせについて検定を取得できたら、すばらしいと思いませんか? MbUnit です。

私が最初に MbUnit を選んだのは、その [RowTest ....] 機能のためでしたが、戻る理由が 1 つも見つかりませんでした。アクティブなテスト スイートをすべて NUnit から移動しましたが、振り返ることはありませんでした。それ以来、私は 2 つの異なる開発チームを福利厚生に切り替えました。

于 2009-08-23T22:40:30.027 に答える
6

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

NUnit は常に先頭を走ってきましたが、ここ 1 年ほどで差が縮まりました。私は今でも NUnit を好みます。特に、以前に流暢なインターフェイスを追加したため、テストが非常に読みやすくなりました。

単体テストを始めたばかりの場合は、おそらく大きな違いはありません。慣れてきたら、どのフレームワークが自分のニーズに最適かを判断するのに適した立場に立つことができます。

于 2008-09-19T20:52:18.667 に答える
6

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

于 2010-04-21T14:17:54.557 に答える
5

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

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

于 2009-01-14T03:23:47.520 に答える
4

コードコントラクトシステムの.NET4.0でのリリースと静的チェッカーの可用性により、理論的にはより少ないテストケースを作成する必要があり、Pexのようなツールがそれらのケースの識別に役立ちます。これを目前の議論に関連させて、契約がテールを​​カバーしているために単体テストで行う必要が少ない場合は、管理する依存関係が1つ少ないので、組み込みの部分を使用してみませんか。最近、私は単純さを重視しています。:-)

参照:

于 2010-11-09T02:35:54.677 に答える
3

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

  • 維持しなければならない共有「テスト」ファイル (無意味)
  • テストリストが複数の開発者/VCS との競合を引き起こす
  • 統合された UI が貧弱 - 混乱するセットアップ、面倒なテスト選択
  • 良い外部ランナーなし

注意事項

  • aspx サイトをテストする場合は、間違いなくMS のサイトを使用します。
  • ソロで開発するならMSでもいい
  • スキルが限られていて、NUnitを構成できなかった場合:)

テストを書いて NUnitGUI やその他のフロント エンドの 1 つを起動する方がはるかに簡単だと思います (testDriven ははるかに高価です)。コマンドライン バージョンでのデバッグの設定も非常に簡単です。

于 2009-05-22T20:54:24.253 に答える