TDD（テスト駆動開発）における品質分析 - 現場のためのソフトウェア開発プロセス - たかのり日記

TDD（テスト駆動開発）における品質分析 - 現場のためのソフトウェア開発プロセス - たかのり日記

TDDでは、常に動くソースコードが確認できるとか、リグレッションテストが簡単とか、メリットは多いのだ...概要を表示 TDDでは、常に動くソースコードが確認できるとか、リグレッションテストが簡単とか、メリットは多いのだけれど、以下のような問題にぶつかることが多い。 テストケースを作成するのに時間がかかる 仕様を満たしているか分からない バグ検出密度（バグ件数／開発規模）が分からない テストケースを作成するのに時間がかかる テストカバレッジを100％に近づけようとすると、テストコードの規模は、開発対象のソースコードの2〜3倍程度になり、かかる工数もばかにならないんだよね。 ただ、かかる工数は、Excelなどでテスト仕様書を書く従来の方法との比較が必要だろう。従来の方法では、仕様書作成とテスト実施に時間が必要だったわけだけど、工数の大小は、 （Excel仕様書）テスト仕様書作成 < （TDD）テストコード作成 （Excel仕様書）テスト実施（手動） >> （TDD）テスト実施（自動） という感じかな。「テスト