ユニットテストまたはTDDを開始するにはどうすればよいですか？
ユニットテストを書き始めるべきだと確信した投稿をたくさん読みました。また、モックを簡単にするために依存性注入（Unity）を使い始めましたが、ユニットを書き始めるべき段階がまだよくわかりません。テストとモック、および開始方法または開始場所。
TDD手法で説明されているように、メソッドの前に単体テストを作成することをお勧めしますか？
ユニットテストのための異なる方法論または方法はありますか？
最初にテスト/後にテスト：
TDDの一部としての「最初のテスト」は、単体テストの場合と同じくらい（それ以上ではないにしても）設計に関係していることに注意してください。これは、それ自体がソフトウェア開発手法です。テストを作成すると、設計が絶えず改良されます。
別の注記：純粋な単体テストの観点からTDDに1つの重要な利点がある場合、TDDを実行するときに間違ったテストを作成することははるかに困難です（不可能ではありませんが）。事前にテストを作成しておくと、テストに合格するために必要なロジックがまだ存在しないため、常に失敗するはずです。後でテストを作成する場合、ロジックはそこにあるはずですが、テストにバグがあるか、間違ったものをテストしている場合は、関係なく合格する可能性があります。
つまり以前に悪いテストを書いた場合、赤を期待するときに緑のライトが表示されることがあります（したがって、テストが悪いことがわかります）。後で悪いテストを書くと、緑を期待したときに青信号が表示されます（悪いテストに気づいていません）。
本
RoyOsheroveの「TheArtof Unit Testing」と同様に、実用的なユニットテストの本は一見の価値があります。実用的な本は、バグを見つけるために試みることができるさまざまなタイプのテスト入力に焦点を絞っていますが、TAOUTは、テストダブル、戦略、保守性などの幅広いトピックをカバーしています。どちらの本も良いです。それはあなたがそれから何を望むかに依存します。
また、ここに Roy Osheroveがユニットテストで行った講演へのリンク 。それは一見の価値があります（彼がさまざまな問題とすべきこと/すべきでないことを理由とともに指摘しているので、彼が記録したテストレビュービデオのいくつかもそうです）。
開始方法
コードを書くことほど良いことはありません。他の多くを参照しないかなり単純なクラスを見つけます。次に、いくつかのテストを書き始めます。
常に「このテストで何を試し、証明したいのか」と自問してください。あなたがそれを書く前に、それからそれにまともな名前を付けてください（通常、呼び出されるメソッド、シナリオ、そして期待される結果を含みます、例えば、スタック上で：「PopWhenStackIsEmptyThrowsException」）。
そこに投げることができるすべての入力、興味深い結果をもたらす可能性のあるメソッドのさまざまな組み合わせなどを考えてください。
ユニットテストに興味がある場合は、それを学ぶための最良の方法を試してみてください。おそらく最初に統合テストを書き始めるでしょうが、それは問題ありません。維持するのが難しすぎる、または書くのに手間がかかりすぎると思われる場合は、どのような種類のテスト（ユニット、機能、統合）があるかについて詳しく読み、違いを学習してみてください。
TDDから始めることに興味がある場合は、ボブおじさんが良い情報源です。特に this 。
ユニットテストの詳細
一貫したテスト結果が得られることを確認してください。同じテストを繰り返し実行すると、一貫して同じ結果が返されます。
テストには構成は必要ありません。
テストの順序は重要ではありません。これは、部分的なテスト実行が正しく機能することを意味します。また、この設計哲学を念頭に置いておくと、テストの作成に役立つ可能性があります。
テストはテストなしよりも優れていることを忘れないでください。作成と保守の容易さを促進する優れたクリーンな単体テストを作成することは困難です。テストフレームワークが難しいほど、それを採用することに反対するでしょう。テストはあなたの友達です。
C＃およびVisual Studioでは、次の手順が非常に役立ちます。
考えて！小さな先行設計を作成します。必要なクラスと、オブジェクトが相互にどのように関連するかを明確に把握する必要があります。 1つのクラス/オブジェクト（実装するクラス/オブジェクト）と1つの関係のみに集中します。そうしないと、デザインが重くなりすぎてしまいます。予備の紙に複数のスケッチ（数個のボックスと矢印のみ）が表示されることがよくあります。
プロダクションコードでクラスを作成し、適切な名前を付けます。
実装するクラスの動作を1つ選択し、そのメソッドスタブを作成します。 Visual Studioを使用すると、空のメソッドスタブを作成するのは簡単です。
そのためのテストを書いてください。そのため、そのオブジェクトを初期化し、メソッドを呼び出し、アサートを行って結果を検証する必要があります。最も簡単なケースでは、アサーションには別のメソッドスタブまたは本番コードのプロパティが必要です。
コンパイルして、テストランナーに赤いバーを表示させます。
緑色のバーが表示されるように、プロダクションコードで必要な動作をコーディングします。
次の動作に移動します。
この手順では、2つのことが非常に重要です。
- 必要なものと、クラス/オブジェクトがどのように見えるかを明確に把握する必要があります。少なくとも1つは時間をかけてください。
- クラス/オブジェクトの動作について考えてください。これにより、テストと本番コードの動作が中心になります。これは、クラス/オブジェクトについて考えるための非常に自然なアプローチです。
最初にテストするか、最初にテストしないか？
通常、テストを既存の製品コードに後付けするのは難しいと思います。ほとんどの場合、これは、テスト中のオブジェクトを初期化する必要がある場合に、他のオブジェクトへの依存関係が絡み合っていることが原因です。 TDDは通常、これを回避します。これは、テストケースでオブジェクトをできるだけ少ない労力で初期化するためです。これにより、結合が非常に緩くなります。
テストを後付けする場合、面倒な作業は、テスト対象のオブジェクトを初期化する作業です。また、依存関係が絡み合っているため、アサーションは多くの作業になる可能性があります。このためには、本番コードを変更し、依存関係を解消する必要があります。依存性注入を適切に使用することにより、これは問題にならないはずです。
はい、推奨 TDDを実行する方法は、最初にテストを作成することです（名前で示されているように、テスト駆動開発）。 TDDを使い始めると、どこからテストを書き始めるかを知るのが難しい場合があるので、それについて実用的にすることをお勧めします。結局のところ、私たちの仕事の最も重要な部分は、コードがどのように作成されたかではなく、機能するコードを提供することです。
したがって、既存のコードのテストを作成することから始めることができます。ユニットテストがどのように構成されているか、どれがうまく機能しているように見えるか、どれがそれほど神ではないように見えるかを理解すると、テストファーストのアプローチにさらに飛び込むのが簡単になります。時間が経つにつれて、私は最初にテストを書くことが多くなることに気づきました。経験を積むと、それは単により自然になります。
Steve Sandersonは、TDDのベストプラクティスに関するすばらしい記事を書いています。
http://feeds.codeville.net/~r/SteveCodeville/~3/DWmOM3O0M2s/
また、多くのTDD原則について説明するASP.net mvcプロジェクトを実行するための優れたチュートリアルセットがあります（途中でASP.net MVCを学習してもかまわない場合） http：//www.asp。 net/learn/mvc-videos / ページの下部にある「ストアフロント」シリーズを探してください。
[〜＃〜] moq [〜＃〜] 最近はホットなモックフレームワークのようですが、それも調べてみてください。
要約すると、アーカイブしようとしているものを検証するためのテストを作成し、それを機能させるためのコードを実装してみてください。
このパターンは、赤-緑-リファクタリングとして知られています。また、テストが1つのコンポーネントに集中できるように、依存関係を最小限に抑えるように最善を尽くします。
個人的には、VisualStudioの単体テストを使用しています。私は筋金入りのTDD開発者ではありませんが、私がやりたいのはこれです：
- 新しいプロジェクトを作成し、システム設計に基づいていくつかの基本的なクラスを定義します（そうすれば、少なくともある程度のインテリセンスを得ることができます）
- ユニットテストプロジェクトを作成し、実装しようとしている機能を満たすためにユニットテストの作成を開始します。
- それらを失敗させる
- それらを合格させる（実装）
- リファクタリング
- 繰り返して、テストをより厳しくするか、しっかりと感じるまでテストを作成してみてください。
また、既存のコードベースに機能を追加することも非常に便利だと思います。新しい機能を追加する場合は、最初に追加するものの単体テストを作成し、コードをステップ実行して変更する必要があるものを確認してから、TDDプロセスを実行します。
重要ではない小さなアプリケーションを選択し、TDDを使用して実装します。最初は新しい考え方は奇妙に感じますが、おそらく1、2週間の練習の後、自然に感じられます。
これはチュートリアルアプリケーションです （ブランチ "tutorial"内）どの種類のテストを作成するかを示します。そのチュートリアルでは、事前定義されたテストケースに合格するコードを記述して、リズムに乗るようにし、後で独自のテストを記述します。 READMEファイルには命令が含まれています。Javaで記述されていますが、C＃に簡単に適合させることができます。
私はTDD、テストファースト開発、前モックと依存性注入を引き受けます。確かに、モックはユニットをより適切に分離するのに役立ちます-したがって、より適切に実行できますnitテスト-しかし、私の考えでは、モックとDIはより高度な概念であり、テストを書くだけの明確さを妨げる可能性があります最初。
モックとDIにはその場所があります。これらは、ツールボックスに含めるのに適したツールです。しかし、彼らは、典型的なテストの新人が持っているよりも、いくらかの洗練された、より高度な理解を必要とします。ただし、最初にテストを作成するのは、思ったほど簡単です。そのため、簡単に実行でき、それ自体が強力です（モックやDIなし）。モック、and TDD、and DIを一度に開始するよりも、最初にモックフリーテストを作成する方が早く簡単に勝つことができます。
テストファーストから始めます。あなたがそれに非常に満足しているとき、そしてあなたのコードがあなたがモックが必要であるとあなたに言っているとき、そしてモックを引き受けます。
私はユニットテスト/統合テストをやりすぎている会社とやりすぎている会社で働いてきたので、両者のバランスが取れていると思います。
TDD-テスト駆動開発をお勧めします。これにより、適切なカバレッジが確保されますが、適切な場所と問題に注意を向け続けることもできます。
したがって、新しい開発のすべての部分に対して最初に行うことは、テストするクラスが1つもない場合でも、単体テストを作成することです。
あなたがテストしているものについて考えてください。次に、テストを実行します。なぜコンパイルされないのですか？ classAが必要だからです。クラスを作成し、テストを実行します。なぜコンパイルされないのですか？ methodAがないからです。メソッド1を記述し、単体テストを再度実行します。テストが失敗するのはなぜですか？ methodAが実装されていないためです。 methodAを実装し、テストを実行します。なぜ失敗するのですか？ methodAが正しい期待値を返さないため...など
開発しながらこのライティングユニットテストのように続け、最終的にテストに合格し、機能の一部が完成します。
テスト駆動開発は初心者にとって混乱を招く可能性があります。TDDを学んでいたときに読んだ多くの本は、電卓クラスの単体テストの書き方を教えてくれますが、実際のアプリを構築するための助けはほとんどないようです。あえて言うなら、データ中心です。私にとってのブレークスルーは、ビヘイビア駆動開発（BDD）とは何か、および外部からテストを開始する方法を理解したときでした。これで、アプリケーションの動作に焦点を当て、それを検証するための単体テストを作成するようにアドバイスできます。 TDDとBDDの間では多くの議論が行われていますが、すべてのレベルで適切に記述された自動テストは付加価値をもたらし、それらを記述するためには動作に焦点を当てる必要があると思います。
ハディハリリはここに素晴らしい投稿をしています http://hadihariri.com/2012/04/11/what-bdd-has-taught-me/
また、TDDに関連するすべての概念を理解するのに役立つと思うトピックに関する記事をいくつかここに書いています。
http://codecooked.com/introduction-to-unit-testing-and-test-driven-development/
http://codecooked.com/different-types-of-tests-and-which-ones-to-use/
スティーブフリーマンの答えを拡張する：デイブアステルの本は「テスト駆動開発-実用ガイド」と呼ばれています。作成しているアプリケーションの種類がGUIアプリケーションである場合、これは役立つはずです。 Kent Becksの本を読みましたが、TDDでプロジェクトを開始する方法がわかりませんでした。 Astelの本は、ストーリーを使用して、最初から最後まで完全な重要なGUIアプリケーションをテストドライブします。 TDDを実際に始めるのに大いに役立ち、どこからどのように始めるかを教えてくれました。
読む NUnitを使用したC＃での実用的なユニットテスト 。睾丸の作成を開始し、コードを構造化して単体テストをより使いやすくするための包括的な情報が含まれています。
以前に単体テストを作成したことがない場合は、いくつかのクラスを選択して単体テストの作成を開始し、さらに単体テストの開発に取り組み続けます。
経験を積むと、たとえばUnityフレームワークを使用してデータベースのモックアウトを開始できますが、この飛躍を遂げる前に、簡単に始めて経験を積むことをお勧めします。
単体テストの書き方に慣れたら、TDDを試してみてください。
DaveAstelsの本は今でも最高の紹介の1つだと思います。 Java用ですが、翻訳できるはずです。
私は、本「例によるテスト駆動型開発-ケントベック」でうまく説明されているケントベックのアプローチを好みます。
あなたの質問から、私はあなたがテストフレームワークについて確信が持てないことを推測することができます-正しいテストフレームワークを選択することはTDDまたはユニットテストを書くために非常に重要です（一般的に）。
TDDの実際的な問題は、「リファクタリング」（テストコードもリファクタリングする必要がある）に時間がかかることだけです。