テスト ユースケース 失敗と反省

以前から疑問だった「XPのテスト駆動開発をすると開発者全員がテストのプロにならねばならないのか?」に対するちょっとした答えが書いてあった。
開発現場で学べること http://jibun.atmarkit.co.jp/lskill01/rensai/devgenba05/devgenba01.html
曰く、「例えば、ユースケースの粒度が大きい場合は、本来単体テストの目的であるとされる「プログラムの分岐条件を網羅する」といったようなテストケースの作成に高いスキルが要求され、ケース漏れも多くなる。逆にユースケースの粒度が細かいと、単体テストの実施量が増え、ドキュメント作成といったような間接的工数が無駄に増えてしまう。」なるほど最も至極。私の問いに関する答えをここから出すとすると「ユースケース粒度をテストの観点から適切なものにする」「クラス分割を適切なものにする」ということであろうか??
単体テスト方針も参考になる。

    • (1)1ユースケースを1単体テストとする。
    • (2)設計者が単体テストのテストケースを作成し、テストデータと予想される結果を日本語で記述する。
    • (3)製造者はテストケースに即したテストデータとJUnitコードを作成し、すべてのケースが正常に動作するまで繰り返し実施する。
    • (4)実施結果を設計者が確認して単体テスト完了とする。


でも一番ためになるのは、『「人間は反省する生き物であり、反省によって成長する。逆に反省しない人間は決して成長しない」と筆者は考える。開発のプロセスもまた同じである。失敗があるからこそ成功するための案が生まれる。そうして成長していくことによって品質の高いシステムも完成するのであろう』かな。今仕事でのToDoリストを作っているが、自分で決めた期日に間に合わない物が多い。それを無くすためにはどうすればいいかを考えている。見積りが甘いのか?飛び込みの仕事のマージンをとっていないのか?そういったことが大事なのであろう。