0

私は最近、TDD について読んでいますが、TDD が提唱されているのは、テストが容易で結合の少ないコードになると思われるためです (およびその他の理由)。

ローマ数字の変換と数字から英語へのコンバーターを除いて、実用的な例をあまり見つけることができませんでした。

これらの 2 つの例を観察することで、TDD の典型的な赤-緑-リファクタリング サイクルと、TDD のルールの適用を観察しました。しかし、これは通常、パターンを観察してコードに実装し、その後でテストを作成する場合、時間の大きな無駄のように思えました。または、コードのスタブを作成し、単体テストを作成してから実装を作成することもできますが、これはおそらく TDD である可能性がありますが、この継続的なケースバイケースのリファクタリングではありません。

TDD は、適切なアーキテクチャを設計するのではなく、コードに飛び込んで帰納的に実装を構築するように開発者を駆り立てているようです。これまでの私の意見では、TDD の利点は適切なアーキテクチャ設計によって実現できるというものですが、誰もがこれをうまくできるわけではないことは確かです。

そこで、2 つの質問があります。

  1. TDD を使用しても、最初に設計することはほとんどできないということを理解するのは正しいですか (TDD のルールを参照してください)。
  2. コーディングを開始する前に適切な設計を行うことでは得られないもので、TDD によって得られるものはありますか?
4

2 に答える 2

0

質問に答えるには:

  1. 「テスト駆動開発」(TDD) は、「テスト駆動設計」と呼ばれることがよくあります。これは、この実践がコードの優れた設計につながるためです。失敗する単体テストを作成すると、テスト駆動型の設計アプローチを余儀なくされるため、テストに合格するために必要なものだけを実装できます。つまり、テストを作成するために記述しているコードの設計を考慮する必要があります。合格。

  2. TDD アプローチを使用する場合、開発者はテストに合格するために必要な最小限のコードを実装します。プロジェクトの開始後に要件が変更された場合、事前に適切な設計を行うことは通常無駄になります。

あなたは、「TDD は、適切なアーキテクチャを設計するのではなく、開発者がコードに直接飛び込んで、帰納的に実装を構築するように促しているように見える」と言っています。ソフトウェア開発にアジャイル アプローチを採用している場合でも、事前にアーキテクチャを構築する必要があります。調査 (たとえば、スクラム方法論を使用している場合、プロジェクトの開始時に開発「スパイク」を作成します) を行い、プロジェクトの開始に必要なアーキテクチャの最小量を確認します。この段階では、現在の知識に基づいて決定を下します。たとえば、小さなデータセットで作業する必要がある場合は、通常の DB を使用することを選択し、巨大な DB がある場合は、NoSQL ビッグデータ DB を使用することを選択する可能性があります。 .

ただし、アーキテクチャの一般的なアイデアが得られたら、プロジェクトの進行に合わせて設計を進化させて、プロセスのできるだけ遅い段階でさらにアーキテクチャに関する決定を行う必要があります。プロジェクトが進行するにつれて、アーキテクチャと要件は常に変化します。

さらに、SO に関するこのかなり人気のある投稿は、TDD が明らかに努力する価値がある理由をさらに説明します。

于 2013-10-01T21:55:50.580 に答える
0

ええと、私は少し前にあなたの立場にあり、同じ質問をしました. それ以来、私は TDD についてかなりの量の読み物をしてきたので、TDD を少しいじることにしました。

TDD に関する私の経験を次の点に要約できます。

  1. TDD は正しく行われた単体テストであり、ATDD/BDD は正しく行われた TDD です。

  2. 事前にデザインするかどうかは、完全にあなた次第です。BDUFを実行しないようにしてください。手が汚れるまで要件を完全に理解することはできないため、途中でほとんどを変更することになると信じてください。
    OTOH、始めるのに十分なデザインを行うことができます。クラス図、シーケンス図、ドメイン モデル、アクター、および共同作業者は、すべてを理解しようとする設計段階でハングアップしない限り、まったく問題ありません。
    まったくデザインをしない人もいます。彼らはただコードを話させ、リファクタリングに集中します。
    私見、あなたのアプローチのバランスをとってください。コツをつかむまで設計を行い、テストを開始します。行き止まりになったら、ホワイトボードに戻ります。
    もう 1 つ、アルゴリズムの 解明など、TDD では解決できないことがあります。これは、最初に設計する必要があるものがあることを示す非常に興味深い投稿です。

  3. コードが既にある場合、単体テストは困難です。TDD では、API ユーザーの視点から考える必要があります。このようにして、API からのパブリック インターフェイスが使用可能かどうかを早い段階で判断できます。すべてを実装した後に単体テストを行うことにした場合、それは退屈であり、ほとんどの場合、それは一部のケースのみであり、機能を完成させるためだけにテストケースに合格するだけの人を知っています. つまり、すべての作業の後に自分のコードを壊したいのは誰ですか?
    TDD はこの考え方を破ります。テストは一級市民です。テストをスキップすることはできません。十分な時間がないため、次のリリースまで一部のテストを延期することはできません。

  4. 最後に、コーディングを開始する前に適切な設計を行うことによって得られないものが TDD によって得られる場合、あなたの質問に答えるために、私はコミットメントと言いたいです。
    TDD を実行している限り、コードがテスト可能になるように、優れた OO 原則を適用することを約束します。

于 2013-10-01T20:17:23.267 に答える