テスト駆動開発-納得させてください！[閉まっている]

私は、一部の人々がテスト駆動開発の大規模な支持者であることを知っています。私は過去に単体テストを使用しましたが、簡単にテストできる操作、またはおそらく正しいと思われる操作をテストするためだけに使用しました。完全またはほぼ完全なコードカバレッジは、多くの時間がかかるようです。

1. テスト駆動開発を使用するプロジェクトは何ですか？特定のサイズを超えるプロジェクトにのみ使用しますか？
2. 私はそれを使用する必要がありますか？信じさせて！

OK、TDDの利点：

1. それはあなたがより多くのテストで終わることを意味します。誰もがテストを好むが、それを書くのが好きな人はほとんどいない。テストフローを開発フローに組み込むと、より多くのテストが必要になります。
2. テストへの書き込みは、デザインのテスト容易性について考えることを強制し、テスト可能なデザインはほとんど常に優れたデザインです。なぜそうなるのかは完全には明らかではありませんが、私の経験とほとんどのTDD伝道者の経験はそれを裏付けているようです。
3. TDDの作成には少し時間がかかりますが、コードの品質が向上し、修正するバグが少なくなるため、投資に対する見返りは大きいという調査結果があります。
4. リファクタリングに自信を与えます。単体テストで十分にカバーされているため、他のすべてを壊すことを心配せずに1つのシステムを変更できるのは素晴らしい気持ちです。
5. バグが見つかった場合は、修正プログラムを取得する前にテストを取得する必要があるため、繰り返しバグが発生することはほとんどありません。

あなたは確信するように頼んだので、これらは利点でした。よりバランスのとれた見解については、この質問をご覧ください。

ロバートC.マーティンは元々これらの点を指摘しました-私は私自身の経験からそれらをバックアップできます：

• 単体テストのリグレッションテストスイートを作成すると、自動的にビルドされます。
• デバッグに時間を費やすことはほとんどありません。まるで自分自身を穴にコーディングする場合、デバッガをクラックして開くよりも、最後のテストに合格した時点までコードを元に戻す方が簡単です。
• 数分ごとに、コードが機能することを確認します-すべて（または、少なくともテストでカバーされるすべての動作。TDDを実行している場合は、その割合が非常に高いです）。

私は、プロダクションで作業している場合でも、コードを再生している場合でも、ほとんどTDDを頻繁に実行します。最近、他の方法でコーディングするのは難しいと感じています。

（免責事項：UIの操作はほとんど行っていないため、UIのTDDについては説明できません。）

些細なアプリからSIPスタック全体にいたるまで、TDDはほとんどすべてのことに使用しています。

私が引き継いだレガシーPHP WebサイトではTDDを使用していません。テストがないと痛いです。そして、何かを壊したと言っている回帰テストスイートがないので、サイトの一部を誤って壊してしまうのは非常に面倒です。クライアントには、（a）コードベースのテストを書いたり、（b）プロセスで最初にコードをテスト可能にするための予算がないので、我慢します。

• クライアントがより効果的に提供できる場合はいつでも（それらはおそらくテストとよく関係します-そして、少なくともプロジェクトの終わりの議論を削減します）
• テストの構築に力を注ぐよりも、コードのすべてを共同開発者に通知するのに時間がかかる場合はいつでも-これは思ったよりも早い

何？否定的な答えはありません！？

免責事項：単体テストではありません。人々がTDDと言うとき、私は彼らが書くすべてのコードの80-100％のコードを書く前にテストを書いている病気に聞こえるバージョンを意味すると思います。

私は主張します：

• それはイネーブラーです。リグレッションの問題をキャッチすることがあなたにとって非常に大きな問題である場合、最初からフルオートTDDが価値があると思われる場合は、最後に書いたコードごとにテストを書くことで、実際の問題を無視することができます。

• 人々が本当の問題を無視するのに役立ちます。1つのバグを修正すると、さらに2つのポップアップが発生する、もぐらたたきのゲームに変わると、アーキテクチャが爆発します。フォーカス。本当の問題に焦点を当てます。ほくろを打たなければならない前にほくろを見るのはきちんとしていますが、そもそもそこにいるべきではありません。

• それは多くの時間を食べる。時々バグを見つけました。あまり多くヒットしなかったので、私が書いたすべての新しいものの前にそれをテストする価値があると思われます。起こりそうな問題をキャッチします。エラーを診断しやすいように処理します。検証。オーバーラップ/ボトルネックの重要なポイントでテストします。しかし、大声で叫ぶために、おそらく最初の場所でそれらを持っていたはずのないもので最後のゲッターとセッターをすべてテストしないでください。

• 設計の焦点：優れた開発者でさえ、テストに集中しているときにできる限り最高のコードを作成する方法はまったくありません。適切なデザインを作成できる唯一の方法のように思える場合は、上記の「実際の問題に焦点を合わせる」ことをお勧めします。

• マクロ設計の失敗：現在の仕事のコードベースには、一度も使用されないインターフェイスと、基本的なDRY原則の大規模な違反があり、テストフレームワークとテスト用に人々が書いていることに気付いたときにようやく理解し始めました一般的な。テストは愚かなアーキテクチャにつながるべきではありません。実際には、20個のファイルをコピーして貼り付けてから、そのうち2個のファイルにのみ重要な変更を加えることに関して、なんとかスケーラブルまたはエンタープライズにふさわしいものはありません。考えは、懸念を分離することであり、懸念を中央に分割することではありません。Cruftと無意味な抽象化は、95％のカバレッジがこれまでにないほど高くなります。

• それは本当に人気があり、多くの人が本当にとても気に入っています。それが少なくとも採用する前に、少なくとも技術を推測したり、技術を徹底的に吟味するのに十分な理由ではない場合は、いくつかの妄想を学んでください。