TDDの開始-課題？ソリューション？推奨事項[閉まっている]

StackOverflow https://stackoverflow.com/questions/24965

質問

OK、 TDDの開始 ..しかし、一般的なコンセンサスはやるだけであるということを知っていると思いますが、ゲームに向かう：

  • コレクションを使用する場合、doは、「知っている」などのジェネリックなどに基づいている場合でも、明らかな追加/削除/挿入の成功をテストします。動作しますか？
  • 一部のテストは実装に永遠に時間がかかるようです。たとえば、文字列出力を操作する場合、「より良い」ものがありますか？この種のものについて行く方法？ （たとえば、構文解析する前にオブジェクトモデルをテストし、構文解析を小さなopに分割して、そこでテストします）しかし、それは大きく異なる可能性があり、設定するのは面倒です。
  • 使用するテストフレームワークがないので（作業に費用がかかりません）、「練習」できます。もっと。無料で商用利用できる良いものはありますか？ （現時点では良い 'ol Debug.Assert を使用しています：）
  • おそらく最大の..時々、何が起こるのかわからないことがあります。ないが発生します。つまり、あなたは青信号を取得します。深く掘り下げてコードを試してみますか、それともそのままにして後ですべてが落ちるのを待ちますか（費用がかかります）。

したがって、基本的にここで探しているのは＆quot;ではありませんやる＆quot;しかし、もっと＆quot; これを行い、これに問題があり、これで解決しました＆quot; .. パーソナルエクスペリエンス：）

役に立ちましたか？

解決

最初に、コーディングスタイルで最初にTDDを使用しようとしたときにイライラするのは普通のことです。がっかりしてやめないでください。しばらく時間が必要です。これは、コードの問題を解決する方法を考える上での大きなパラダイムシフトです。手続き型プログラミングからオブジェクト指向プログラミングに切り替えたときのように思います。

第二に、テスト駆動開発は何よりもまず、公開するAPIと消費方法を記述するテストを作成することにより、コンポーネントの設計を具体化するために使用される設計アクティビティであると感じています機能です。このテストは、作業中のタスクをすべて満たすのに十分な機能をカプセル化できるようになるまで、テスト中のシステムを形作るのに役立ちます。

上記のパラグラフを念頭に置いて、質問を見てみましょう：

  1. テスト対象のシステムでコレクションを使用している場合は、アイテムを挿入するためにコードが呼び出されたことを確認し、コレクションのカウントをアサートするように期待値を設定します。内部リストでAddメソッドをテストする必要はありません。項目を追加するメソッドが呼び出されたときに呼び出されることを確認するだけです。これを行うには、テストフレームワークを使用して、モックフレームワークをミックスに追加します。
  2. 文字列を出力としてテストするのは面倒です。すべての結果を説明することはできません。テスト対象のシステムの機能に基づいて、期待するもののみをテストできます。テストは常に、テストしている最小の要素に分割する必要があります。これは、多くのテストがあることを意味しますが、小さくて高速で、必要なものだけをテストし、それ以外は何もしません。
  3. 選択できるオープンソースのテストフレームワークはたくさんあります。私はどちらがベストだと主張するつもりはありません。好きなものを見つけて、使い始めてください。
  4. できることは、あなたが望むことを説明するためにテストを設定することだけです。機能にバグが発生するシナリオが発生した場合、少なくともそのシナリオをテストに追加し、テストに合格するまで機能を変更する機能に関するテストがあります。テストを逃した可能性がある場所を見つける1つの方法は、コードカバレッジを使用することです。

質問1の答えで、モック用語を紹介しました。 TDDの兵器庫にモッキングを導入すると、テスト対象システムの一部ではない部分を抽象化してテストを劇的に簡単にすることができます。モックフレームワークに関するリソースは次のとおりです。

プロセスについて読む以外に、TDDの使用を支援する1つの方法は、人々がそれを行うのを見ることです。 JP Boodhooによる DNRTV のスクリーンキャストを見ることをお勧めします。これらを確認してください：

他のヒント

TDDで最も重要なことは（実際には、ある程度再帰的な方法での素晴らしい結果の1つ）、TDDが依存関係をうまく管理できることです。精巧なセットアップを必要とせずに、モジュールが単独でテストされることを確認する必要があります。たとえば、最終的に電子メールを送信するコンポーネントをテストしている場合、テストでモックできるように、電子メール送信者を依存関係にします。 これは2番目のポイントにつながります-モックはあなたの友達です。モックフレームワークとそれらが促進するテストのスタイル（従来の状態ベースとは対照的な動作）、およびそれらが推奨する設計の選択（＆quot;教えてください、尋ねないでください＆quot; 原則）。

TDDの本質を簡単に覚える3つのインデックスカードは良いガイドです。

とにかく、質問に答える

  1. 「知っている」ことをテストする必要はありません。あなたが書いていない限り、動作します。あなたはジェネリックを書いていなかった、マイクロソフトはしました;）
  2. テストのために多くのことをする必要がある場合、オブジェクト/メソッドも同様に多くのことをしている可能性があります。
  3. TestDriven.NET をダウンロードして、Visual Studioで単体テストをすぐに開始します（Expressエディションの場合を除く）
  4. 発生する正しいことをテストするだけです。失敗する可能性のあるものすべてをテストする必要はありません 。テストが失敗するまで待つ必要があります。

まじで、それをやるだけです。 ：）

私はTDDの専門家ではありませんが、私の見解は次のとおりです。

  • 完全に些細な場合（ゲッター/セッターなど）は、何らかの理由でコードに自信がない場合を除き、テストしないでください。
  • それが非常に単純ではあるが重要な方法である場合は、テストします。とにかくテストはおそらく簡単に書くことができます。
  • 発生しないことが予想される場合、特定の潜在的な問題がテストしているクラスの責任である場合、それが正しく処理されることをテストする必要があると思います。現在のクラスの責任でない場合は、テストしないでください。

xUnitテストフレームワークは多くの場合無料で使用できます。そのため、.NetのユーザーはNUnitをチェックし、Javaがあなたの目的であればJUnitをチェックしてください。

上記のアドバイスは適切です。無料のフレームワークのリストが必要な場合は、 xUnit Frameworks List 」。これが役に立てば幸いです：）

私の意見では（走行距離は異なる場合があります）：

1-書いていない場合はテストしないでください。あなたがそれを書いて、あなたがそれをテストしていないなら、それは存在しません。

3-皆が言ったように、xUnitは無料で素晴らしい。

2＆amp; 4-何をテストするかを正確に決定することは、自分自身と永遠に議論できることの1つです。契約による設計の原則を使用して、この線を引きます。 「オブジェクト指向ソフトウェア構築」をご覧ください。または「実用プログラマー」詳細については。

テストは短く、「アトミック」にしてください。各テストで最小の仮定をテストします。各TestMethodを独立させ、統合テストのために、各メソッドに対して新しいデータベースを作成します。テストごとにデータを作成する必要がある場合は、「Init」を使用します。方法。モックを使用して、テストのクラスを依存関係から分離します。

私は常に、「これがすべてのケースで機能することを証明するために書く必要があるコードの最小量はいくらですか？」

昨年、私はTDDの利点をますます確信してきました。 途中で学んだこと： 1）依存性注入はあなたの友達です。プラグインアーキテクチャをアセンブルするためのコントロールコンテナとフレームワークの反転については説明していません。テスト対象のオブジェクトのコンストラクターに依存関係を渡すだけです。これは、コードのテスト容易性に大きな利益をもたらします。 2）私は改宗者の情熱と熱意を持って出発し、モックフレームワークを手に入れて、モックを使用してあらゆることを始めました。これは、多くの苦痛なセットアップを必要とする脆弱なテストにつながり、リファクタリングを開始するとすぐに失敗します。正しい種類のテストダブルを使用します。インターフェースを尊重するだけの偽物、テスト対象のオブジェクトにデータをフィードバックするスタブ、相互作用が必要な場所のみを模擬します。 3）テストは小さくする必要があります。各テストでテストされる1つのアサーションまたは相互作用を目指します。私はこれをやろうとしていますが、ほとんどはそこにいますこれは、テストコードの堅牢性と、後で再検討する必要がある場合のテストの複雑さに関するものです。

TDDで私が抱えていた最大の問題は、標準化団体の仕様と、事実上の標準であるその標準のサードパーティの実装との連携でした。私は、フェンスの向こう側の実装が標準を助言文書として見ていることを見つけるためだけに、仕様書の文字にたくさんの本当に素晴らしい単体テストをコーディングしました。彼らはそれでかなりゆるやかでした。これを修正する唯一の方法は、実装と単体テストをテストし、必要に応じてテストとコードをリファクタリングすることでした。本当の問題は、コードとユニットテストがすべて良好であるという私の側の信念でした。そうではありません。ユニットテストと同時に、実際の出力を構築し、機能テストを実行する必要があります。プロセス全体を通して、ユーザーまたは利害関係者の手に至るまで、小さなメリットがあります。

これに加えて、ブログの投稿は、このスレッドを閲覧している人に役立つかもしれないので、テストを開始することについての私の考え（この議論と私自身の研究に従ってください）。

＆quot; TDD-はじめにテスト駆動開発＆quot; -これまでにいくつかの素晴らしいフィードバックをいただいており、皆さんが提供しなければならないことを本当に感謝しています。

これが役立つことを願っています！ ：）

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top