TDDを含むプロジェクト/タスクの見積もりを見積もる際のガイドラインはありますか？
たとえば、完了するのに1日かかるタスクの通常の開発と比較した場合、TDD駆動タスクはどれだけ多くかかる必要がありますか？50％多い時間ですか、それとも70％多い時間ですか？開発者が言語とテストフレームワークに精通していると仮定して、利用可能な統計はありますか？
1007 次
5 に答える
2
違いは最初は大きく、経験とともに減少しますが、おそらく常に要因です
開発者がTDDを上手に利用できるようになると、従来のコーディングとTDDの実装時間の差は小さくなります。TDDの初心者、さらには中級者でさえ、どのテストを作成するかを決定することに巻き込まれたり、リファクタリング後に破棄されるテストをさらに作成したりする可能性があります。経験を積むと、TDD'erは、作成するテストをより適切かつ迅速に選択できるようになるため、より効率的になります。
従来型とTDDの比率の絶対的な下限が何であるかはわかりません。1：1.5だと思いますが、ほとんどの開発者が、コードを書くよりもはるかに少ない速度でコードをテストドライブできるとは信じられません。
また、他の人が言っているように、TDDの実行に費やされた余分な時間の大きな見返りは、テスト駆動コードのデバッグ時間が大幅に短縮されることです。
于 2010-04-29T12:37:15.340 に答える
1
コーディング時間は、テストレス開発とほぼ同じである必要があります。デバッグ時間は約99％短縮されます。
于 2010-04-28T22:56:58.127 に答える
0
TDDを使用してコードを生成する場合の別の見返りは、記述されたテストが回帰スイートになることです。次に、テストにより、これらのアクティビティがはるかに安全になります。
- 事後のリファクタリング。
- 同じコードのさらなる開発。
- バグ修正。
（NB wrt Bug Fixing、いくつかのケースを実装するのを忘れたか、仕様に遅れて追加されたときのことを何度か覚えています。追加の開発は、テストが実施されたということでした。）
于 2010-05-01T17:21:51.713 に答える
0
数学的な答えが必要な場合、私の発見はテストに費やされた時間です：生産は2：1です（控えめです-テストに費やされた時間の大部分はTHINK時間です）。ただし、TDDは着実な進歩を遂げるのに役立つため、現在の（非TDD）見積もりに3X係数を適用することはできません。時間を費やすことはありません。
- 不要なものをコーディングする
- 休憩と修正の輪で実行されます。または既存の機能を壊します。
- 最後に明確なバグ発見と修正フェーズ
- ゼロに近いデバッガーとステップスルーセッションを接続します
私の頭のてっぺんから、私はあなたの既存の見積もりの2倍に行きます。
于 2012-06-04T06:10:00.713 に答える