■

最近読んだ本

バグがないプログラムのつくり方 JavaとEclipseで学ぶTDDテスト駆動開発 (Be agile!)

+TDD研究会

TDD研究会のハンズオンと書籍のサンプルプログラムでTDDを体験してみての感想。

TDDは、
○:品質保証の手法
×:開発者の為の設計手法
には納得。

テストケースを記述しながら、どんどん機能を作りこんでいくやり方。
ここでのテスケースの抽出の観点は、"バグをみつける"ではなく、"機能用件を満たす"こと。

テストケースがあるので、積極的にリファクタリングが行える。
リファクタリングとテストを繰り返すことにより設計とコードの品質がどんどん上がっていくのが良い。
ペアプログラミングで行った方がより効果的で、品質の高いものができる。

コードを記述しながら進めていくので、コードレベルまで落とし込んだ詳細設計書は不要。
詳細設計と並行して実装を行うので、設計者=プログラマであるか、設計者と密にコミニュケーションが取れる環境が必要。

実装を始める前のTODOリストの洗い出しの精度が大事。ここで異常系までしっかり洗い出しておければ、TDDのテストケースでも
ある程度品質を保証できるのでは無いか。

※上記の書籍でも、同値分割、境界値分析をすると良いと書かれてはいたが、サンプルコードのテストケースをみると特に境界値を意識しているとは思われないケースが挙げられていた。

+拡張型TDD

・テスト設計を行う(同値分割、境界値分析)
・テストコードのリファクタリング
・テストケースの作り込み(境界値を使うなど)
・テストスイートの作り込み
・冗長なテストを無くす

"機能を作り込む"観点に、"バグをみつける"観点を盛り込み、開発終了後にある程度の品質を保証することにより、
後工程の単体テストの工数を削減できるのではないか？

・実装前にテスト設計を行う必要があり、TDDのリズムが崩れる。(実装、テストで頭を切り替えないといけない)
・後工程の単体テストと重複する箇所がある。
・仕様変更により、テストコードとテスト仕様書のメンテナンスが発生する。
→
☆テストコードを書くのであれば、後工程のテスト仕様書にはそのテスト項目を書かないなどの割り切りが必要だと感じた。