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

Question

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

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

Answer 1

OK、TDDへのいくつかの利点：

1. それはあなたがより多くのテストになってしまうことを意味します。誰もが好きです 持っている テストですが、好きな人はほとんどいません 書き込み 彼ら。開発フローへのテスト作成の構築は、より多くのテストになってしまうことを意味します。
2. テストに書くことで、あなたのデザインのテスト可能性について考えるようになり、テスト可能なデザインは ほとんど 常により良いデザイン。なぜこれがたまたまそうなのかは私には完全には明らかではありませんが、私の経験とほとんどのTDDエバンジェリストの経験はそれを聞いているようです。
3. これが研究です TDDは書くのに少し時間がかかりますが、高品質のコードを取得し、したがって修正するバグが少ないため、投資収益率が十分にあります。
4. それはあなたにリファクタリングに自信を与えます。ユニットテストでかなりカバーされているため、他のすべてを壊すことを心配することなく、1つのシステムを変更できることは素晴らしい気持ちです。
5. あなたが見つけたすべての人が修正を受ける前にテストを受ける必要があるので、あなたはほとんど繰り返しバグを取得することはありません。

あなたは確信するように頼んだので、これらは利益でした。見る この質問 よりバランスのとれたビューのために。

Answer 2

ロバート・C・マーティンはもともとこれらのポイントを作りました - 私は自分の経験からそれらをバックアップすることができます：

• あなたが行くにつれて、あなたは自動的にユニットテストの回帰テストスイートを構築します。
• デバッグに時間を費やすことはほとんどありません。まるで穴に自分自身をコーディングした場合、デバッガーをクラックするのではなく、最後のテストが通過した時点までコードを元に戻す方が簡単です。
• 数分ごとに、コードが機能していることを確認します - すべて（または、少なくともテストでカバーされている動作のすべて、TDDを行っている場合は非常に高い割合です）。

生産に取り組んでいるかプレイコードに取り組んでいるかにかかわらず、私は常にTDDを行っています。最近、他の方法でコーディングすることは難しいと思います。

Answer 3

（免責事項：私はほとんどUIのことをしていないので、UIのTDDについて話し合うことはできません。）

些細なアプリからSIPスタック全体まで、私が行うほとんどすべてのものでTDDを使用しています。

私は引き継いだレガシーPHPウェブサイトでTDDを使用していません。テストを受けていないのは苦痛だと思います。そして、私は何かを壊したと言って回帰テストスイートがないので、サイトの誤って誤って壊れているのは激しく迷惑です。クライアントは、（a）コードベースのテストを作成する予算を持っていません。

Answer 4

• クライアントをより効果的に提供できるときはいつでも（テストに関連する可能性があります - そして、少なくともプロジェクトの終わりのディスカッションで削減されます）
• それがあなたの共同開発者をより時間がかかるときはいつでも、あなたの共同開発者はテストの構築に努力するよりもコードのすべてのものについて通知してください - そして、これはあなたが思っているよりも早いです

Answer 5

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

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

私は主張するだろう：

• それはイネーブラーです。回帰問題をキャッチすることがあなたにとって非常に大きな問題である場合、最初からフルオートTDDが価値があるように思われる場合、あなたが書く最後のコードのすべてのテストを書くことは、実際に本当の問題を無視するのに役立つかもしれません。

• それは人々が本当の問題を無視するのを助けます。 1つのバグを修正すると、さらに2つのポップアップが吹き飛ばされるモールのゲームに変わります。集中。本当の問題に焦点を当てます。ほくろが叩かなければならない前にモールを見るのはきちんとしていますが、そもそもそこにいるべきではありません。

• それは多くの時間を食べます。私は時折バグを打った。私はそれほど多くの人を襲っていないので、私が書いたすべての新しいものをテストでプレフィックスすることは価値があります。それらが起こる可能性が高い問題をキャッチします。診断が簡単になるようにエラーを処理します。検証。オーバーラップ/ボトルネックの重要なポイントでテストします。しかし、大声で叫ぶためには、すべての最後のゲッターとセッターを、おそらくそもそもそれらを持つべきではなかったものでテストしないでください。

• 設計フォーカス：優れた開発者でさえ、テストにも焦点を当てているときにできる限り最高のコードを書くことはまったくありません。それがあなたがまともなデザインを持つことができる唯一の方法のように思えるなら、私は上記を「本当の問題に焦点を合わせている」ことについて見ることをお勧めします。

• マクロデザインの失敗：私の現在の仕事のコードベースは、人々がテストフレームワークのために書いてテストのために書いていることに気付いたときについに理解し始めた基本的な乾燥原理の大規模な違反と、一度以上使用されることのないインターフェイスに悩まされています全般的。テストは愚かなアーキテクチャにつながるべきではありません。いいえ、実際には、20のファイルをコピーして貼り付けることについて、どういうわけかエンタープライズにふさわしいものは何もありません。アイデアは、懸念を分離することであり、真ん中に分割するのではありません。 Cruftと無意味な抽象化は、これまでに95％のカバレッジを持っている以上の費用がかかります。

• それは本当に人気があり、本当に多くの人が本当に好きです。それが少なくとも2番目の推測や採用の前にあらゆる技術のがらくたを拒否するほど十分な理由でない場合は、あなたにいくつかの妄想を学びます。