静的テストの効果は高い
| ||
| ||
|
導入効果の観点で注目したいのは，静的テストにおける「ソース・コードの妥当性をチェックする」機能である。この機能は，あらかじめ設定したコーディング規約に照らし合わせてソース・コードを自動解析し，バグなどを指摘する。バグの発見は開発工程の後半になるほど難しくなるため，「静的テストでバグの発見に注力することは，動的テストで同じことをやるのに比べて3倍の投資効果がある」（東陽テクニカ ソフトウェア開発部 ASDグループ 係長 黒田正好氏）という。しかも，テスト・ツールとソース・コードのみで解析が行えるため，導入しやすい。
コーディング規約は，例えば「等価演算子（==）を使っていないか」といった，製品が提供する「ルール＊3」を組み合わせて作成する（表1[拡大表示]）。また，製品によっては，ユーザー独自に作成したルールを追加できる。設定したルールは，ファイル化することで，開発チーム内で共有可能だ。
静的テストの結果は，ソース・コード上にコメントで表示される。そのコメントからリンクされるヘルプ画面には，エラーの理由や詳細説明だけでなく，エラーのサンプル・コードや修正候補なども表示される（写真1[拡大表示]）各製品で表示される項目の差は少ないが，説明の詳しさや文章の分かりやすさ，などをチェックしておくべきだろう。
“ツールを使う”意識を浸透させる
静的テスト機能を使えば，Java推奨のコーディング規約への準拠やバグが発生しやすいコードの除去により，プログラムの品質が高められる。また，ソース・コードの標準化を行うことによる可読性の向上や，ヘルプ画面で学習することによるJava開発者のスキル向上なども見込める。
ただし，ツールの効果を引き出すには，いくつか注意点がある（図3[拡大表示]）。日本IBM＊4でJtestを使って品質管理を行っているテクニカル・コンピテンシー Java技術 副主任ITスペシャリスト 古賀亜紀子氏は，「まず，テスト・ツールを中心に据えた開発手順を策定し，全員が利用することでツールの効果が高まることを開発者に周知させる」ことが重要だという。たった一人の開発者がツールによるテストを怠るだけで，プロジェクト全体のプログラム品質は低下してしまう。
またコーディング規約を作成する際は，「すべてのルールを適用すると，とんでもない数の解析エラーが出力され，本当に重要なエラーを見落としかねない」（古賀氏）ため，適用するルールの見極めが欠かせない。そのためには，Javaの知識や開発経験が求められる。まずは，重要度に応じて用意されているデフォルトのルール・セットを適用し，必要に応じてカスタマイズするのがよいだろう。
このように，ツールの導入効果を高めるには，開発者の意識とツールの機能，両面からの土台作りが必要になる。開発の途中でスポット的に導入しても，限定的な効果しか得られないことには注意したい。
動的テストは補完が必要
動的テスト機能は，自動でスタブやドライバ，テスト・データなどを生成し，テストを実施する＊5。
ただし現時点では，自動生成機能の完成度はそれほど高くない。例えば，Jtestを利用する日本IBMでは「（前バージョンの3.31では）適正といえないテスト・データを生成することもあるので，自動生成機能は使用していない」（古賀氏）という。そのため，「平均で70％のテスト・ケースをカバーしている」（テクマトリックス 技術本部 第二技術部 ASQグループ グループリーダー 西田啓一氏）ことを前提に，テスト・データの正当性を検証し，適宜，補完する必要がある。
動的なら無償ツールも有力
動的テスト・ツールを検討する場合は，無償ツールも視野に入れたい。
例えば，XP＊で利用されるテスティング・フレームワーク「JUnit＊6」は，スタブやドライバ，テスト・データの自動生成などはできないが，テストの実行環境を提供する。テスト方法は，JUnitが用意するテスト・クラスのひな型にテスト・コードを記述して実行する。利用方法がシンプル，Javaのドキュメント生成ツール「Javadoc」が使用できる，などのメリットがあり，「XP以外のJava開発でも利用価値は十分ある」（永和システムマネジメント システム本部 ソリューション部 ITソリューショングループ 田中真弓氏）。
そのほか，GUI画面テスト用のHttpUnit＊7，サーバー・サイドJavaテスト用のCactus＊8なども無償である。HttpUnitは，ツール上にWWWブラウザをエミュレートする機能を備える。有償のGUI画面テスト・ツールは，これに加えて項目の入力値のテスト・データを自動作成する機能や，GUI上の動きをシナリオとして記録して回帰テストを行う機能なども備えるが，それらが必要なければ，HttpUnitで十分である。
