nUnit、MBUnit などの他のテスト フレームワークよりも MSTest の方が TDD/test first の方が難しいことを何度も読みました。インフラストラクチャ ポリシーにより、MSTest が唯一のオプションになるのはいつですか? 私は主に VS 2008 Team Suite について疑問に思っていますが、一部の MSTest 機能がそれらのバージョンにも含まれるようになったため、VS 2008 Pro のヒントも適していると思います。
Daniel Auger
質問する
4240 次
10 に答える
29
MSTest は確かに、一部のオープン ソース フレームワークほど効率的でも拡張性もありませんが、実行可能です。この質問は、代替案ではなく、MSTest で生活を楽にすることについて尋ねているので、ここに私の MSTest のヒントを示します。
- ショートカット。Haacked が言ったように、ショートカットを学ぶのに数秒かかります。
- 現在のコンテキスト。MSTest は非常に遅いため、可能な場合は現在のコンテキストでのみテストを実行してください。( CTRL+R , CTRL+T )。カーソルがテスト メソッド内にある場合、これはメソッドのみを実行します。カーソルがメソッドの外にあり、テスト クラス内にある場合、これはテストのみを実行します。そして名前空間などで
- 効率的なテストと組織。ドッグスローです。効率的なテストを作成することで、できる限り最善を尽くします。遅いテストを他のテスト クラスまたはプロジェクトに移動して、速いテストをより頻繁に実行できるようにします。
- WCF でのテスト。サービスをテストする場合は、RUN テストではなく DEBUG テストを実行して、Visual Studio が ASP.NET 開発 Web サーバーを起動できるようにしてください。これらが起動したら、RUNに戻ることができますが、常にDEBUGする方が簡単なので、考える必要はありません.
- 構成ファイル。テスト実行構成を編集して、.config ファイルをテスト実行フォルダーに移動します。
- Source Safe との統合。MSTest は SourceSafe を嫌っており、相互に感じていることに注意する必要があります。MSTest はテスト ファイルをソース管理下に置き、それらをソリューションに追加する必要があるため、テストを実行するたびにソリューションをチェックアウトする必要があります。そのため、SourceSafe はマルチ チェックアウト モードで実行して、仲間の開発者を殺さないようにする必要があります。
- 綿毛を無視するMSTest を使用すると、多数の異なるウィンドウとビューが得られます。Test Runs、Test View、Test Lists ... それらはすべて役に立ちません。テスト結果に固執すれば、あなたはもっと幸せになるでしょう.
- 「単体テスト」に固執します。新しいテストを追加するときは、順序付きテスト、単体テストを追加するか、ウィザードを使用して実行できます。単純な単体テストだけに固執します。
于 2008-08-27T17:40:52.447 に答える
13
MSTest を使用せざるを得ない場合は、キーボード ショートカットを学習してください。彼らはあなたの人生を少し楽にします。
現在のコンテキストでのテスト: CTRL+ R、T
ソリューション内のすべてのテスト: CTRL+ R、A
現在のコンテキストでテストをデバッグ: CTRL+ R, CTRL+T
ソリューションですべてのテストをデバッグ: CTRL+ R, CTRL+A
于 2008-08-27T05:49:18.117 に答える
6
ここに興味があります。私が理解していないのは、人々がMSTestで利用可能なすべてのオープンソースツールを比較し始め、それをバッシングし始めるということです。それがどれほど扱いにくいか、どれほど直感的でないかなどについてコメントします。私見、それはxUnitフレームワークとは根本的に異なるためです。並列実行用に最適化されています。
静的なClassInitialzeとCleanupを持ち、テストごとに一意のTestContextを持っているという癖でさえ、すべて次世代のために-少なくともMS言語のWindowsビジネスプログラマーにとっては-並列プログラミングの概念です。
何万もの単体テストがあるプロジェクトで作業するという不幸がありました。彼らは事実上ほとんどのビルド時間を費やしていました！MSTestを使用すると、それを非常に管理しやすいタイムラインに短縮できます。
于 2008-10-17T08:51:18.157 に答える
3
私の同僚である Mike Hadlow は、私たちが MSTest を完全に嫌う理由をここでかなりよくまとめています。
彼は自分のプロジェクトからそれを削除することに成功しましたが、私は現在、より多くの政治が関与するより大きなプロジェクトに取り組んでいるので、まだ使用しています.
その結果、MSTest を実装した人は誰でも TDD を理解していません。M$ ばか者のように聞こえて申し訳ありませんが、そうではありません。しかし、非常に貧弱なツールを我慢しなければならないことに腹を立てています。
于 2008-09-16T15:33:56.547 に答える
2
前述のように、別のマシンで MSTest を使用するには完全な IDE をインストールする必要がありますが、これは少し面倒です。これは、ユニット テストがハイエンドのビジュアル スタジオでのみ機能し、他の方法で実行できるようにする必要があるためだと思います。
また、MSTest は非常に遅いです。これは、各テストの間に各テストのコンテキスト全体を再構築するためです。これにより、以前のテストが失敗したか、現在のテストに影響を与えていないことを確認できますが、速度が低下します。ただし、/noisolation フラグを使用すると、MSTest プロセス内ですべてのテストが実行されます。これはより高速です。IDE で高速化するには: VS IDE では、[ツール] - [オプション] に移動し、[テスト ツール] を選択します。テスト実行というサブ項目を選択し、右側のダイアログで、「テスト実行間でテスト実行エンジンを実行し続ける」というチェックボックスがオンになっていることを確認します。
于 2009-04-28T12:33:30.887 に答える
2
MSTest に関する深刻な問題は見たことがありません。具体的には、何について話しているのですか？実際、私たちは NUnit から MSTest に移行しています。ただし、これの理由はわかりません。
于 2008-08-27T05:05:41.903 に答える
2
mstest には多くの構成ファイルがあり、理解しにくいものになっています。
mbunit を選んだもう 1 つの理由は、mbunit の「ロールバック」機能です。これにより、このテストで実行されたすべてのデータベースをロールバックできるため、実際に完全な回路テストを実行でき、テスト後に池が汚染されることを心配する必要はありません。
また、mstest には RowTest 機能がありません。
ビルド プロセス内で依存関係として mbunit を実行することをお勧めします。ビンと一緒にフローティングするだけで簡単に参照できます。インストールは不要です。
于 2008-08-27T05:08:26.437 に答える
2
- MSTest には「高い摩擦」があります。MStest と MSBuild と比較して、NAant と MbUnit でビルド スクリプトを取得することです。比較なし。
- MSTest は遅いです MbUnit と NUnit は私の経験ではより高速です (ガリオはここで役立つかもしれません)
- MStest は、有線の構成ファイルなど、必要のないものをたくさん追加します。
- MSTest には、他の OS テスト フレームワークの機能セットはありません。xUnit と MbUnit をチェックしてください
使い方が難しすぎて、もっと良いオプションがたくさんあります。
于 2008-09-30T10:26:37.040 に答える
1
的を射ていない質問に答えるために、私の答えは「おそらく NUnit はあなたの顔から離れているだけです。」
免責事項: 私は xUnit の MS バージョンを実際に使用した経験はありませんが、「別のマシンでテストを実行するためだけに巨大なアイデアをインストールする必要がある」などの問題を耳にします。これは完全なノーノーです。それ以外に、MSには、アイデア全体に反するある種のIDEベル/ホイッスルを介して、初心者向けの正しいパスをゆがめるこの方法があります。クラスからテストを生成することは、私が1年ほど前に覚えていることのように..それはテスト運転の要点全体を無効にします-設計はRGRの小さなステップから出現するはずです:テストを書いて合格するリファクタリング. そのツールを使用すると、エクスペリエンス全体が奪われます。
私は私の説教をやめます..今:)
于 2008-08-27T06:13:35.610 に答える
1
私は何年も NUnit を使用して TDD 開発を行ってきましたが、役割が変わったため、MSTest を約 4 か月間使用しています。
MSTest が誰かの TDD を止めるとは思いません。基本的な assert やモック フレームワーク (私は Rhino Mocks を使用しています) など、TDD に必要なすべてのコア要素がまだあります。
MSTest は Visual Studio と密接に統合されています。この統合の最適なコンポーネントは、組み込みのコード カバレッジ ツールです。
しかし、MSTest を使用しない理由はいくつかあります。私の意見では、2つの最大のターンオフは次のとおりです。
- アサート オプションの欠如 (NUnit と比較して)
- 遅いテスト ランナー (NUnit に比べて遅い)
これは、アサートを記述すると、遅いテスト ランナーと組み合わせてより多くのコードが必要になることを意味し、プロセス全体が NUnit よりも遅くなることを意味します。オープン ソースのオプションも、コミュニティでより多くのサポートを受けています。
CI に TFS を使用している場合は、NUnit でテスト結果を公開するために、いくつかのフープ/ハックをジャンプする必要があります。それに比べて、MSTest を使用して TFS でテストを実行するのは、非常に簡単で簡単です。私がずっとNUnitに行くよりもTFSに触れないなら、それはただより良いです。
于 2010-06-22T06:34:20.777 に答える