2

.NET v1の期間中、私はNUnitとNAntの追加ツールを使用して、テスト駆動および自動ビルドの作業習慣を開発するよう同僚を説得することに成功しませんでした。.NETFramework2.0とVisualStudio2005 Team Suiteが登場したとき、私はチームにテストの作成を「強制」し、VisualStudio内で視覚的なテストを提供することができました。さらに、追加のMSBuildタスクを使用してプロジェクトファイルを微調整し、ビルドの自動化をさらに実行することができました。

もちろん、これはマイクロソフトが完璧なシステムを提供したことを意味するものではありませんが、彼らはこれらを正しいステップで進めてきたと思います。これらすべての機能がフレームワークと製品に組み込まれ、「ネイティブ」になることで、開発者をより良い開発手法に移行させることが少し簡単になりました。

オープンソースのオプション（私は見逃している）を長い間忘れていたので、NUnitとNAntの現在の化身はどのような価値提案を持っているのだろうかと思います。チームにMSBuildまたはMSTestを使用しないように説得するために、この段階でどのようなケースを主張できますか？

明確化：私の会社は純粋なMicrosoftSIです。Visual Studio Team Suiteエディション、Database Professionalエディション、TFSなどを使用できます。VisualStudioProfessionalエディション以下は使用していません。

4

2 に答える 2

5

MSBuildはかなり優れたビルドツールです。NAntとCruisecontrol.Netと組み合わせて数回使用しました。NAntとNAntcontrib拡張機能を組み合わせると、NUnit、NCoverなどのOSSツールの処理が少し柔軟になりますが、MSBuildがVSソリューションを構築できるという事実は大きなプラスになります。ビルドスクリプトを作成する最も簡単な方法は、NAntを使用してビルドのさまざまな部分（ビルド、fxcop、テスト、カバレッジなど）を呼び出し、MSBuildを使用して実際のビルドを行うことです。

私はMSTestについてあまりよく言うことができません。たとえばビルドサーバーにインストールするのは遅くて面倒です。柔軟性はそれほど高くなく、単体テストよりも統合テストに適しているように見えるあらゆる種類の「エクストラ」があります。軽量のXUnit.Net、MBUnit、またはNUnitは、単体テストにはるかに適していることがわかりました。ここでは速度が重要です。コードの変更による影響をすばやくフィードバックするために、テストを頻繁に実行する必要があります。移植性も重要です。チームシステムがインストールされていないマシンでMSTestに必要なように、多くのセットアップやハッキングを行わずに、どこでもテストを実行したいと考えています。ユニットテストは新しいものではありませんが、まだ多くの開発が行われています。ベストプラクティスは大きく変化し、ツールも変化します。私はしません VisualStudioで数年ごとにアップグレードされるだけのツールに縛られたい。3つのOSS.net単体テストツールはすべて、拡張可能に設定されています。MSTestはそうではありません（私が見た限りでは）。

于 2008-10-21T07:38:09.643 に答える
4

私の見解では、NUnitは.NETでの単体テストの事実上の標準です。これは無料で、VisualStudioのどのエディションでも簡単にテストを作成できます。MSがMSTestをVS2005Proで利用できるようにした場合（VS 2008 Proの場合と同様）、それは今では引き継がれている可能性がありますが、手遅れだと思います。

ReSharperは基本的にVisualStudioに不可欠であり、NUnitで非常にうまく機能する優れたテストランナーが含まれていると思います。オープンソースプロジェクトを開発している場合、なぜVS2008ProまたはVS2005Team Suiteが必要なのですか？

MSBuildとNAntは少し異なります。これは、MSBuildがフレームワークまたはSDKのいずれかにバンドルされているためです（今はどちらかを思い出せません）。ただし、NAntの方が作業しやすい環境だと思います。MSBuildは、生の作業を行うのに明らかに優れています。ソリューションを構築する」ビット-ただし、NAntから呼び出すことができます。

于 2008-10-21T07:38:35.807 に答える