単体テストの効用

年末年始の休み中に読み返そうと思って、ボーリス バイザーの本や体系的ソフトウェアテスト入門を家に持って帰ったが、読まずじまい。。。

==

「テスト環境」を見直し、開発生産性・品質向上を実現！【第1回】 by TechTargetジャパン

単体テストには大きい利点があるにも関わらず、開発チームが首尾よく単体テストを実行していくためには多くの努力と挑戦が必要となる。最も大きい挑戦の一つは、実質的にすべての開発グループに存在するスケジュールに対するプレッシャーである。開発者が一つのプログラムを書いた後で、開発者には選択肢がある。それは、テストコードを書くべきか。それとも、次の機能のプログラムを作成すべきか。

ほとんどの開発者が、スケジュールに対するプレッシャーを感じ、テストコードを書かないことを選択し、それを正当化するのは簡単である。しかも、単体テストに最適なプログラムコードを書くことは単体テストよりも多くの時間が必要となり、プレッシャーのかかった開発者にとっては「テストのため」のプログラミング手法へと変更することは間違っていると感じてしまうのは最も現実的な話なのである。

単体テストがプログラムを開発することと異なる作業と感じている限り、この抵抗感は存在してしまう。それではどうすればよいのだろうか。

スケジュールに対するプレッシャーも、単体テスト実施の抵抗のひとつだが、もっと大きい壁が存在する場合があると思う。単純にいえば「単体テストの軽視」。もちろん、ある程度の教育を受けたエンジニアであれば、「工程が進むにつれてバグ修正コストが大きくなる」ということは知っている。でも知っているだけで、それを回避するところまでたどり着いていないエンジニアやチームも多いんじゃないかと思う。

テスト駆動開発を含めて、単体テストに注目した開発をすることで、品質の高い設計・品質の高いモジュール・品質の高い開発手法を手に入れられる。チームメンバーに単体テストのエクササイズをさせて、単体テストの効果を実感させ、単体テスト重視の第一歩を踏み出させるのもテストマネージャーの仕事かな、と思います。

あとは、各テスト工程で重複したテストをすることによるムダを嫌う、というのもあるか。