unit-testing - コーディングと単体テストに費やされた時間の比率

Question

新しい機能をコーディングするための見積もりが与えられた場合、単体テストをコーディングするための典型的な見積もりは何ですか? これは、コードを維持するための見積もりとは異なりますか?

Answer 1

私の時間は、単体テストの時間と機能コードの時間でほぼ同じです。

これを見て時間の無駄だと言う人もいますが、アプリを実行し、アプリがたどる可能性のあるすべてのパスをステップ実行する以外に選択肢がない場合、単体テストに費やされる時間は実際には開発者のテストに費やす時間。もちろん、開発者のテストをあまり行わなければ、QA から戻ってきたバグの修正に時間を費やすことになります。

いずれにせよ、単体テストの作成に費やす時間は、プロジェクトに費やす時間よりも実際に時間を節約します。

コードを保守するとき (わずかな変更、機能の小さな追加) になると、違いが生じる可能性があります。変更中のコードがすでに完全にカバーされており、変更にテストの変更が必要ない場合、時間は 0 です。

ただし、テスト時間の節約ははるかに大きくなります。残りのコードをカバーするテストを既に作成しているため、新しいコードを追加したり、アプリを実行したりしなくても、変更から派生する偶発的な変更を発見できます。

Answer 2

単体テストのコーディングに時間の約 50% を費やしていると思います。個人的な経験以外でその効果を測定するのは困難ですが、3 つの主なメリットがあることがわかりました。

• 設計についてもっと考える必要があり、結果としてより良いコードを書く傾向があります。
• すべてを壊してしまうのではないかと恐れることなく、何ヶ月も何年も先にリファクタリング/維持することができます
• 単体テストで見つけられる些細なバグを探し出す時間を無駄にしないため、プロジェクトに費やされる全体の時間が短縮されます

Answer 3

作業しているコードによって大きく異なることがわかりました-ゼロから何かを作成し、テスト駆動する場合、おそらくテストなしで機能を実装するのにほぼ同じ時間がかかりますが、量をより長く節約できます発見されるバグの数と、そのコード ベースをどれだけ簡単に維持および拡張できるか。この場合、コードが期待どおりに動作せず、デバッガーを使用して何が起こっているのかを調べる必要があるという頭を悩ませる瞬間を避けるため、テストを使用して記述する方が高速であると主張する人もいるかもしれません。 TDD が通常許可するよりも変更セット。

既存の「レガシー」コード ベース (Michael Feathers がレガシーを定義するように) の上に機能を実装しようとしている場合、慎重にリファクタリングを行う必要があるため、テストを使用して機能を実装する場合、テストを使用しない場合よりも大幅に時間がかかることがよくあります。通常、テストを作成する前に行うことができます。この場合、単体テストを作成することは依然として長期的なメリットがありますが、その長期的なメリットが当面のコストに対して正当化されるかどうかについて、さらに検討する必要があります。

通常、レガシー コード ベースの追加コストがかかるにもかかわらず、ユニットまたは機能にかかわらず、何らかの形式の自動テストを常に推進します。これがないと、メンテナンスが非常に困難なコード ベースで行き詰まる可能性が高く、頻繁にリグレッションが発生し、機能し続けることを確認するために一定の反復的な手動テストが必要になります。