TDDが設計に関するものである場合、なぜそれが必要なのですか？[閉まっている]

TDDの第一人者は、TDDがテストではなく、デザインに関するものであることをますます伝えています。TDDなしで本当に素晴らしいデザインを作成する開発者を知っています。彼らはTDDを実践すべきでしょうか？

TDDは、最高の最終設計を実現するのに役立つだけでなく、より少ない試行でそこに到達するのに役立ちます。

私は、どのデザインが最良だと思うかを決める前に、問題に2つか3つの突き刺しをしていた。今、まさにその同じ時間が、テストの作成と正しい設計への私の心の集中に費やされています。そして、おまけとして、一連の繰り返し可能なテストが残されています。勝つ！

そうは言っても、TDDが何も提供しない人々が必然的に存在するでしょう。終了時に自動化された繰り返し可能なテストが残っている限り、問題ありません。

この特定の TDDの第一人者が本当に述べようとしているのは、TDDが設計プロセスであるということではありません（残念ながら、多くの人々がそのように解釈しています）。ここでのメッセージは、TDDなどのプロセスを使用すると、正しく実行すると、全体的な設計が向上する傾向があるということです。

基本的な概念は、TDDよりもはるかに古い概念です。テスト容易性のための設計。SOLIDの原則、特に単一責任の原則を厳密に遵守している場合、コードのテストが非常に簡単になります。一方、デザインが少しだらしがちである場合は、ユニットテストを作成して、これをより頻繁に行うように強制するプロセスを見つけて、（a）必要なものを理解することのフラストレーションを回避することができます。 （b）実際のテストを書くよりも依存関係の設定に多くの時間を費やします。

あなたはしていない持っている、このことの利点を得るためにTDDを追跡するために、ありませんテストを書くために助けを早期に -あなたがいない場合は前または中に、クラスを実装し、好ましくは、非常にすぐ後。時間がかかりすぎると、作者が話している「ダーティハイブリッド」テストのリスクが発生します。テストは壊れやすく、無害なリファクタリング中に壊れる傾向があるため、あまり価値がありません。 -scaleは、非常に困難なプロセスを再設計します。

テストを書かなければ、本当にテスト容易性を設計しているかどうかはわかりません。コードカバレッジが15％だけの無計画な「機能テスト」は考慮されません。

もちろん、テストを1つも作成しなくても、優れたデザインを作成できます。ただし、優れたデザインであると確信していますか？テストで明確に指定されていない場合、どのようにしてわかりますか？テストでは多くの問題が明らかになり、QAプロセスでは目に見えるバグが見つかる可能性がありますが、設計上の不適切な決定は明らかになりません。

TDDを学ぶために努力している人からの単純な答え：それは必要ありませんが、TDD がもたらす主な利点は、非常に簡単に言えば、自信：アプリケーションが動作するという信頼です。ユースケースが満たされているという確信。あなたのロジックが「Foobar」モジュールにとって健全であるという自信。CEOが彼が読んだいくつかの新しいクレイジーな機能を追加したいときに、コードが適切に構造化され、6か月後に保守可能で拡張可能になるという自信。アプリケーションが成長したときに、アーキテクチャがバラバラにならないように、または新機能を試用するために厄介なハックのゴブを必要としないための基礎が築かれているという自信。

上記は少し伝道的であるように聞こえますが、それが私がTDDの利点を理解する方法です。TDDを使用して優れた堅固でよく設計されたデザインを作成できたとしても、手を正しく行うように強制し、適切に行われていることを証明し、さらに重要なことには、正しく保つためのベースラインを提供します。TDDに手を出していないことから、コードをクリーンにし、適切なソフトウェアエンジニアリングの概念に従うことを余儀なくされました。それ以外の場合は、しばしば「乱雑な」ハックコードをもたらす「可能な最も迅速なこと」を行います。

私の経験からしか話せません。私にとってTDDは、これまでにないいくつかのことを開発スタイルの習慣ツールボックスに持ち込みました。ただし、TDDがすべての問題を解決するわけではないことを再度述べておきます。私は常に、探索と本番環境に対応した実装を分離するようにしています。探索段階のTDDは絶対に必要ではなく、速度が低下しています。一方、本番対応のコードでは、短期的にも長期的にも、開発者の精神的健康とプロジェクトのカルマにとって非常に貴重ないくつかの利点がもたらされます。

• TDDは、実装する前に私に考えさせます。これは通常、多くのシュートを防ぎ、解決策を忘れる非常に良い習慣です。
• 問題のごく一部を考えさせられ、ぴったり合う小さな断片への解を分解することを余儀なくさせます。
• 問題に適合しない何かをスタブ/モック/偽造する必要があるときはいつでも、私は自然に「WTF、それと結合する必要がない場合はなぜこれを行うべきなのか」という理由で、それは私に非常に分離したコードを書かせます。そして、物事のつながりをよりよく理解できるようになります。
• これにより、コードを簡単に実行できるチェックのセットが得られるので、コードのデバッグの苦痛な「var_dump」、「p」、「pp」、「echo」スタイルを実行する必要がありません。何が悪いのか、いつ間違っているのかを報告するだけです。まだチェックがない場合は、簡単なテストを追加して何度もチェックするだけです。
• デプロイする前にすべてのテストに合格すれば、コードが機能することが確実になります。次に、爪を食べる代わりに、ケーキを食べてコーヒーを飲み、午後を楽しんでいます。
• 高レベルのテストは、何かをリファクタリングする必要がある場合に非常に便利です。私のモジュールが外の世界にいくつかの機能を提供する必要があり、機能/統合/きゅうりのテストを開発してそれが正しく機能していることを証明した場合、そのコードから地獄をリファクタリングすることは非常に勇敢になります。テストがなく、リファクタリングが必要なコードに何度か直面しました。その場合、実際には2つの方法がありました。1）コードをドロップする2）変更をスキップして、そのままにしておきます。

TDDで修正できないことが1つあります。構築しているものを構築する方法がわからない場合、TDDはソリューションを生成しません。問題と解決策の大まかな「設計」または概要が必要です。TDDは、より高品質のコードを使用して、よりエレガントで保守可能な方法で実装するだけです。

とうとう、私はTDDの実践に基づくBDD用語で考えることを好みます。BDDを使用すると、ドメインの語彙を使用してソリューションを実装し、ソフトウェアを問題に適合させることができます。

優れたデザインを実現するには多くの方法があるかもしれませんが、「素晴らしい」、または「良い」を構成するものについては、間違いなく多くの異なる解釈があります。ほとんどのTDD担当者はこの定義についてあなたに同意しないと思います-あなたが素晴らしいと感じたコードを見てみたら、私たちはそれを素晴らしいとは思わないでしょう。TDDは非常に特定の品質に私たちを駆り立て、これらの品質は非TDDコードではめったに見られません。

明らかに、テスト容易性はそれらの特性の1つであり、包括的な特性です。非常に小さいメソッドとクラスはおそらくサブ特性であり、これは優れた命名につながります。TDDを実行せずにこれらの品質を達成するプログラマーをご存知かもしれませんが、私はそうではありません。