ユニットテスト、NUnit、またはVisual Studio？

ユニットテストを実行するためにVisual Studio（時々リシャーパー）を使用しています。

NUnitについて聞いたことがありますが、それについてはあまり知りません...

気にする必要がありますか？ビジュアルスタジオより良いものを提供できますか？

NUnitを使用する必要があるのはなぜですか？

NUnitにはMS-Testに比べていくつかの利点があります

1. スイート属性-テストを集約して個別に実行できます（たとえば、高速テストと低速テストのある大規模プロジェクトに役立ちます）
2. 読み取り可能なAssertメソッド、たとえばAssert.AreEqual(expected, actual)vsAssert.That(actual, Is.EqualTo(expected))
3. NUnitには頻繁なバージョン更新があります-MS-TestにはVSバージョンごとに1つしかありません。
4. ResharperやTestDriven.NETなどの多くの統合ランナー
5. 予期される例外メッセージアサーション-NUnitで属性を使用して実行できますが、MS-TestでTry-Catchを使用して実行する必要があります
6. [TestCase]！NUnitはパラメーター化されたテストを可能にします。

私の現在の視点（平均8人の開発者による8か月の開発後）から、次の理由でMSTestを使用しないことをお勧めします

• フレームワーク自体は非常に遅いです。私があなたが書いたテストコードを意味するのではなく、それはあなたの管理下にあります。つまり、テストスイート、単一のテストなどを実行している場合でも、それらのテストを実行しているフレームワークは低速です。
• 複数の開発者がそれに取り組んでいるとき（メタデータなどの再作成など）常に複雑化につながるTest-Metadataファイルを保持する必要性。他のすべてのテストスイートはメタデータファイルを必要としません。テストを整理するのはいいことですが、名前空間、クラス、メソッド名を使用して同じことを実現できます。
• 継続的インテグレーションを行っている場合、ビルドマシンでユニットテストを実行するには、そのマシンにVisual Studioをインストールする必要があります。

つまり、8か月前に再度決定する必要がある場合は、おそらくNUnitを選択します。統合されたテスト結果レポートを持っていないかもしれませんが、開発者はよりシームレスなテスト体験をするでしょう。

ここに私のMSテストの経験があります

• 約3800テストでMSテストを実行しています。
• テストの実行を開始するだけでは非常に長い時間がかかります。これは、単一のテストを実行するときに苦痛です。
• テストの実行には約1GBのメモリが必要です。いいえ、テストのメモリリークが原因ではありません。頻繁にOutOfMemoryExceptionsに遭遇します。
• それは多くのリソースを使用するので、バッチファイルからテストを実行し始めています。では、統合全体は何に適しているのでしょうか？
• バギーで不安定です：
  • たとえば、テストから[無視]属性を削除すると、テストに関する情報がどこかにキャッシュされるため、属性が認識されません。テストリストを更新して問題を解決するか、VSを再起動する必要があります。
  • 参照アセンブリをランダムにoutディレクトリにコピーしません。
  • 展開アイテム（使用する追加フ​​ァイル）が正しく機能しません。それらはランダムに無視されます。
• vsmdiおよびtestrunco​​nfigファイルに非表示の（テストコードでは表示されない）情報があります。気にしないと動かないかもしれません。
• 機能的にはNUnitに匹敵するかもしれませんが、VSテスターエディションの使用を検討すると非常に高価です。

加えて：我々はいくつかのより多くのテストを今持っています、いくらと言うことさえできません。OutOfMemoryExceptionsやその他の不安定性の問題のため、Visual Studioからこれらをすべて実行することは不可能です。テストはスクリプトから実行します。Visual Studioでテスト結果を表示するのは簡単ですが、ソリューションが開いていると、VSがクラッシュします（毎回）。したがって、テキスト検索を使用して失敗したテストを検索する必要があります。統合ツールの利点はもうありません。

別のアップデート：現在、VS 2013を使用しています。多くのことが変わった。彼らは、MSテストテストランナーを、私たちが始めてから3回目に書き直しました。これは多くの重大な変更を引き起こしましたが、どちらの新しいバージョンもより良いことはしていませんでした。MS Testのすばらしい機能を使用していなかったことをうれしく思います。それらはすべてサポートされなくなったためです。それは本当に残念です。便利なので、すべての単体テストをビルドして実行するために、まだスクリプトを使用しています。Visual Studioは、テストの実行を開始するのに数分を要しました（コンパイル後、最初のテストが開始するまでの時間測定）。彼らはおそらくアップデートでそれを修正し、これは私たちのプロジェクトの特定の問題かもしれません。ただし、同じテストを実行すると、Resharperの方がはるかに高速です。

結論：少なくともResharperと組み合わせると、MS Testは役立ちます。そして、彼らが最終的にテストランナーの記述方法を見つけ、次回Visual Studioを更新するときにこの種の重大な変更を行わないことを願っています。

NUnitはVisual Studio と組み合わせて使用できます。それは別個のプログラムではなくフレームワークです。だから、あなたがそれがあなたに合っているかどうかを気にすることができます:)。

代替テキストhttp://i3.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=nunitit&DownloadId=61802

「プラグインをインストールすると、ツールメニューの下に新しいサブメニューが表示されます。」

http://nunitit.codeplex.com/を参照してくださいインポートのを。

また、SOの検索を使用して多くを見つけることができます。このトピックでは、たとえば、MS標準のテストに対するNUnitの利点を示します。

NUnitに対するMS-Testの最大の利点は、MS-TestがReflectionを使用してモックオブジェクトを生成できることです。私はそれがとても便利だと思いました

NUnitはVSのStandardエディションで動作します。

他の人はわかりませんが、NUnitはユニットテストを実行するための素晴らしいGUIとコンソールを提供し、テストが失敗したか成功したか、また何時に実行したかの詳細を示すNUnitテストの実行結果のレポートを生成できます。あなたのユニットテストを取る

NUnitはユニットテストフレームワークであり、resharperでもサポートされています。Microsoftのユニットテストフレームワークを使用していると思うので、NUnitはMicrosoft製品の代替手段にすぎません;）

NUnitのホームページへのリンクは次のとおりです。http：//nunit.org

NUnitの、試験を並行して実行されません。むしろ、すべてのテストは単一のスレッドで実行されるように見えます。MSTestでは、各テストは個別のスレッドでインスタンス化されます。これにより、実行がインターリーブされます。したがって、テストAの成功がテストBに依存している場合、テストAの実行中にテストBが実行を開始する可能性があるため、テストAは失敗する可能性があります。

Visual Studioを使用している場合はユニットテストを実行するためにNUnitを使用する必要があり、java（Netbeans）を実行している場合はユニットテストにJUnitを使用する必要があります。

簡単な電卓の単体テストの例を示します

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using SimpleCalculator;
using NUnit.Framework;

namespace CalculatorTest
{
    [TestFixture]
    public class Class1
    {
        public Calculator _calculator;
        [TestFixtureSetUp]
        public void Initialize()
        {
            _calculator = new Calculator();
        }
        [Test]
        public void DivideTest()
        {
            int a = 10;
            int b = 2;
            int expectedValue = a / b;
            int actualvalue = _calculator.Divide(a, b);
            Assert.AreEqual(expectedValue, actualvalue,"Failure");

        }
    }
}