チーム全体がTDDに慣れたら、TDDの実際のオーバーヘッドはどうなりますか？

TDDの実行に費やす時間の割合。

このコストと報酬の割合は、プロジェクトのライフサイクル中に変化すると想定しています。

私は想像する最初の段階は、添付のより多くのコストが、少しの報酬を持っています。さらに（リファクタリング中）テストの利点を得ることができます。

あなたの時間の30-50％がユニットテストを書いていると聞いています。ただし、これらのテストを記述することで節約される時間は考慮されていません。

これに関するみんなの経験はどうですか？

ウェス

編集時間の節約だけでなく、時間の節約もできますか？バグ修正とリファクタリングで？

あなたの時間の30-50％がユニットテストを書いていると聞きました。しかし、それは節約された時間を考慮していません

私の経験では、それは50％以上です。

テストを作成すると、ソリューションは非常に簡単になる傾向があります。したがって、テストの作成に70％から75％の時間を費やすことは奇妙ではないと思いますが、「プロダクションコード」（テスト中のコード）の作成に費やす時間ははるかに少なく、デバッガーで実質的に時間を費やすことはありません。

バグを見つけるのが早ければ早いほど、修正にかかる費用は安くなり、TDDはそれを非常に助けます。過去2か月（8か月のプロジェクト）がバグの修正に費やされたプロジェクトに取り組んできましたが、TDDを使用すると、このフェーズはほぼ完全になくなります。

私にとって、本当の価値はメンテナンスにあります。コードベースをテストで継承すると、変更するのが怖くなりません。テストに合格しても、何も破らなかったように感じます。変更を行うことを恐れていないので、何かが正しくない場合はリファクタリングしてもかまいません。つまり、コードをよりクリーンに、デザインをより適切に適合させ、理論的には変更を適用できます。ブードゥー教のコードとは対照的に、誰もが触れるのが怖いです。

単体テストを実行するたびに、コードを手動でテストするのにかかる時間を節約できます。

テストを書くために必要とされる時間の30％から50％は、より良い（テスト可能な）ソフトウェア設計の利点により、かなり相殺されます。

自動化されたテストの記述には、テストを手動で実行する場合の4倍の時間がかかるとしましょう。つまり、自動化されたテストを4回実行すると、自動的に費用が発生します。その後、自動テストを実行するたびに無料です。

これは、テストが自動化された単体テストであっても、自動化された機能テストであっても当てはまります。すべての機能テストを自動化できるわけではありませんが、それらの多くは自動化できます。さらに、自動テストは人よりも信頼性が高くなります。毎回まったく同じ方法でテストを実行します。

単体テストを持つことは、メソッドの基礎となる実装を（パフォーマンスまたはその他の理由で）リファクタリングできることを意味し、単体テストはメソッドの機能が変更されていないことを確認します。これは特に、ユニットテストでメソッドの機能を指定するTDDに当てはまります。

TDDは、多くの場合、時間と費用を費やすのではなく、コードの品質に向かって測定されます。ただし、コードの品質が向上すると、開発者とそれらを使用するすべての人がより良い仕事をすることができます（時間の節約、コストの削減、幸せなど）。http://davidlongstreet.wordpress.com/2009/04/29/new-software-metric-wtfs-per-minute/

テストの記述は、機能要件と非機能要件の検証を自動化するのに役立ちます。TDD（実際にはBDD、高レベルTDD）を採用するように私を説得した1つのビデオ：http : //video.google.com/videoplay?docid=8135690990081075324#

• 機能テストを書くことは、開発フェーズの早い段階でバグ/問題を発見するのに役立ちます。大きなコードベースがあると仮定します。単体テスト/仕様では、「すべてのテストに合格しました」/「2つのテストに失敗しました。行xyzを参照してください」のみを表示する必要があります。開発とテストの両方を行うために必要なのは開発者チームだけです。単体テスト/仕様がなければ、印刷されたステートメントと期待されるステートメントを手動で比較し、どのメソッド/クラスにバグがあるかを手動でトレースする必要があります。これを行うには、おそらく2つの別々のチーム（開発者とテスター）が必要です。

• 書面によるテストは、開発者が進行状況と直面した問題を説明するのに役立ちます。

• TDDは、コードの保守性、適応性、柔軟性を実現するのに役立ちます。開発者がテスト可能な小さなチャンクを作成し、テスト可能な大きなチャンクにまとめることを推奨します。他の方法のラウンド（リファクタリングの練習の一部）も動作しますが、条件はしっかりしたテストを作成したことです。その結果、適切に記述されたモジュラーコードを作成できます。

TDDを使用すると、次のことがわかります。

• 顧客が要件の変更を要求する（要件を満たす）
• より良いコード記述方法が発見されました
• チームの仲間にはコード改善のための提案があります
• 他の人にコードを説明/渡す必要があります

開発プロセスは小さなステップを踏むため、TDDは退屈な場合があります。

私たちのケースでは、40％に近いと推定します。しかし、これ以上の段階に進んだとは思いません。開発者によって肉付けされたコードスケルトンと、同じく肉付けされたテストスイートの両方を生成するコードジェネレーターがあります。テスト作業のほとんどは、実際に適切なテストデータを追跡（または作成）して、完全なカバレッジを確保するために行われます。

重要な長期的措置は、コードの品質とコードの信頼性だけでなく、チームを不注意にテストすることもありません

短期的な対策は、テストを自動化するROIです

たとえば、先週、内部アーキテクチャの変更のために1000を超えるコード変更を行い、自動テストスイートを開始し、スリープ状態になりました。

テストの実行には28分かかりました。彼らはすべて合格しました。同じ40以上の受け入れテストを手動で実行すると、約6時間かかります。

別の例：前回の反復で、手動テストではおそらく検出されなかった微妙なバグで、テストシナリオの1つを回避しました（自動テストでは、手動テスターではほとんど行われないdb整合性チェックが実行されます）。私はそれを理解して修正する前に、そのテストシナリオを約50回実行する必要がありました。テストシナリオの操作を手動で実行するには、約50分かかります。つまり、1日で41.6人時の労力を節約できます

自動テストのROIを事前に計算する方法はありません。テストを実行する必要がある回数を正確に知ることができないためです。

しかし、私にとって、自動テストのROIはほぼ無限です。

単体テストを複雑なアルゴリズム、それらを自動生成できるケース、および回帰に制限するのに非常に役立ちます。

多くの場合、コンポーネントテストはかなり単純なコードに対して素晴らしい仕事をします。さらに、テストはインターフェイスにのみ結合されるため、実装の変更ははるかに安価です。

粒度の細かい単体テストで完全にカバーすると、実装を変更またはリファクタリングするためのオーバーヘッドが大きくなります。