まず、自分のコーディング スタイルで TDD を使い始めたときにフラストレーションを感じるのは当然のことです。がっかりしてやめないでください。しばらく時間を与える必要があります。これは、コードで問題を解決する方法についての私たちの考え方における大きなパラダイム シフトです。手続き型プログラミングからオブジェクト指向プログラミングに切り替えたときのように考えるのが好きです。
次に、テスト駆動開発は何よりもまず、コンポーネントが公開する API とその機能をどのように使用するかを最初に記述するテストを作成することによって、コンポーネントの設計を具体化するために使用される設計活動であると感じています。テストは、たまたま取り組んでいるタスクを満足させるのに十分な機能をカプセル化できるようになるまで、テスト対象のシステムを形作り、形成するのに役立ちます。
上記の段落を念頭に置いて、あなたの質問を見てみましょう。
- テスト対象のシステムでコレクションを使用している場合は、アイテムを挿入するためにコードが呼び出されたことを確認し、コレクションのカウントをアサートするように期待を設定します。内部リストで Add メソッドをテストする必要はありません。アイテムを追加するメソッドが呼び出されたときに呼び出されたことを確認するだけです。これを行うには、テスト フレームワークを使用して、モック フレームワークをミックスに追加します。
- 文字列を出力としてテストするのは面倒です。すべての結果を説明することはできません。テスト対象のシステムの機能に基づいて、期待するものだけをテストできます。テストは常に、テスト対象の最小の要素に分割する必要があります。つまり、多くのテストを行うことになりますが、小さくて高速で、必要なものだけをテストするだけのテストです。
- 選択できるオープンソースのテスト フレームワークは多数あります。どちらが良いか議論するつもりはありません。気に入ったものを見つけて使い始めましょう。
- 実行できることは、実行したいことを考慮してテストをセットアップすることだけです。機能にバグを導入するシナリオが発生した場合、少なくともそのシナリオをテストに追加し、テストに合格するまで機能を変更するための機能に関するテストがあります。テストを見逃した可能性のある場所を見つける 1 つの方法は、コード カバレッジを使用することです。
質問 1 の回答で、あざける用語を紹介しました。TDD の武器庫にモッキングを導入すると、テスト対象のシステムの一部ではない部分を抽象化してテストが劇的に簡単になります。モック フレームワークに関するいくつかのリソースを次に示します。
プロセスについて読む以外に、TDD を使用する際に役立つ 1 つの方法は、人々がそれを行っているのを見ることです。DNRTV で JP Boodhooのスクリーン キャストを見ることをお勧めします。これらをチェックしてください：
OK、これらは、私が紹介した用語がどのように使用されているかを理解するのに役立ちます. また、 Resharperと呼ばれる別のツールと、それが TDD プロセスを容易にする方法についても紹介します。TDD を行う場合、このツールはあまりお勧めできませんでした。プロセスを学習しているようで、他のツールを使用してすでに解決されている問題のいくつかを見つけているだけです。
プラグマティック プログラマーのテスト駆動開発に関するKent Beck の新しいシリーズを追加してこれを更新しなければ、私はコミュニティに対して不正を行っていると思います。