思考のサルベージ(その６)
各工程で心がけたい思想を掘り起こしてみる
「単体テスト」について考えてみましょう。各工程のなかでは割と地味な作業ですが、この作業に割り当てられる時間は全体スケジュールに大きく響いてきます。
いつやるの？
V字モデルに従えば、
ですね。 ただ、私が経験した開発現場ではコーディング後にちゃんと単体テストの時間をとるところは少ないですね。実装がすんだらひとまず動かしそのまま結合テストへ、そしてBug対応が優先され、結局単体テストは後回しというケースが多いです。
何をどれだけやるの？
いろんな考え方があると思いますが、「単体テスト」を関数単位のホワイトボックステストと考えましょう。テスト項目は詳細設計書から作るということになります。ただそうなると、全ての関数に対して関数仕様書が必要です。詳細設計の期間にそれだけの事をする時間は正直ありません。結局時間の制約で、コードからテスト条件を起こして最低限カバレッジ100パーセントを目指すなんて本末転倒な作業になることが割と当たり前に起きますね。
ほんとの目的は？
当たり前のことですが前工程は後工程をスムーズに進めるためにあるということ。つまり、単体テストの目的は後工程の「結合テスト」に耐えうるように各関数、モジュールの品質を高めることにあります。
後付けの単体テストに意味はあるか？
本来の目的は果たせませんね。ただ、後工程に突入したとしても、関数、モジュール単位の「品質を高める」という作業は無駄ではありません。「ただの儀式」と考えて、やっつけ仕事にしないように心がけたいですね。
何か掘り起こせた？
- 本来の目的は「結合テスト」に耐えうるように各関数、モジュールの品質を高めること。
- 後付けになったとしても、各関数、モジュールの品質を高めるという目的は変わらない。
おしまい
V字モデルできちっとやれたら気持ちいいでしょうね。 いろいろなジレンマを抱えながら、多くの人がこれからも「単体テスト」に立ち向かっていくのでしょう。
