JUnit作成は本当はプログラミングスキルの必要な作業です

多くの開発プロジェクトで試験の自動化をきちんと行えているところはどのくらいの割合あるのでしょうか？理想的なプロジェクトでは単体試験はもちろん、画面の打鍵テストや性能のベンチマーク試験など多くの試験を自動化するのが良いとされていますが、私の経験上そこまでできているプロジェクトは時間やスキルの制約から皆無でした。
ただし、最低限JUnitの単体試験だけでもきちんと作成、メンテナンスできているだけでも相当優秀で、それだけでもまったく試験の自動化をやっていないところに比べるとプログラムの品質には雲泥の差があるように思います。
試験の自動化がしやすいアーキテクチャーの構築は開発に携わるアーキテクトの仕事としては非常に大切なポイントであると思います。そして、試験の基本である単体試験*1だけに絞って考えてみても

• モックオブジェクトを利用した単体試験
• データベースにデータを挿入して行う試験
• DIコンテナーやEJBコンテナー上でコンポーネントを結合して行う試験
• スクリプトで画面操作をエミュレーションする試験

などさまざまなパターンを考えて適切な方法を考える必要がありますし、試験クラス自体のメンテナンス性を高めるためにはリファクタリングを積極的に行ってロジックの共通化などを随時図る必要があります。（誰も緑色の状態にメンテナンスできず、そもそも試験の内容自体適切でないようなJUnitのクラスはほとんどゴミでしかありません。）

xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))

には、効果的な単体試験の自動化を行う上でヒントとなる大量のパターンやリファクタリングが説明されています。かなり分厚い英語の本ですし、チームの全プログラマーが読むというのは現実的でないかもしれませんが、最低限アーキテクトやチーフプログラマーは読んでおくべき本だと思います。一般にPGは単価の低い新人にまかせるという発想がありますが、試験については特にその傾向が強いことは残念なことです。効果的な単体試験のクラスを設計できるスキルは本当は非常に重要なプログラミングスキルだと思いますし、そういうスキルは見逃さずきちんと評価してもらいたいものです。

*1:ここではPGの行う試験という意味。厳密にモジュールやクラスの単体試験のみではないので用語定義によっては結合試験まで含まれることに注意。