エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
TDD(テスト駆動開発)における品質分析 - 現場のためのソフトウェア開発プロセス - たかのり日記
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
TDD(テスト駆動開発)における品質分析 - 現場のためのソフトウェア開発プロセス - たかのり日記
TDDでは、常に動くソースコードが確認できるとか、リグレッションテストが簡単とか、メリットは多いのだ... TDDでは、常に動くソースコードが確認できるとか、リグレッションテストが簡単とか、メリットは多いのだけれど、以下のような問題にぶつかることが多い。 テストケースを作成するのに時間がかかる 仕様を満たしているか分からない バグ検出密度(バグ件数/開発規模)が分からない テストケースを作成するのに時間がかかる テストカバレッジを100%に近づけようとすると、テストコードの規模は、開発対象のソースコードの2〜3倍程度になり、かかる工数もばかにならないんだよね。 ただ、かかる工数は、Excelなどでテスト仕様書を書く従来の方法との比較が必要だろう。従来の方法では、仕様書作成とテスト実施に時間が必要だったわけだけど、工数の大小は、 (Excel仕様書)テスト仕様書作成 < (TDD)テストコード作成 (Excel仕様書)テスト実施(手動) >> (TDD)テスト実施(自動) という感じかな。「テスト