テストファーストと品質指標の関係

　開発者は新しい物好きなのでＸＰだなんだと騒ぐが、現状のシステム開発プロジェクトでは会社の標準に従うのは当然のことだし、そこに「オレは好き勝手やるから」というのはただのアナーキーでしかない…ので、なかなか普及しない背景ってのは根強くあると思う。
　で、ある部分の話ではあるけども、ユニットテストについて議論する時に「テストケース書く工数がかかるじゃん」という壁がいままで取り沙汰されてはいるけども、実際にはもうひとつ、「品質指標との親和性が疑問」というものがあると思う。
　ユニットテストを昔ながらのウォーターフォールモデルに倣う分類にすれば、おそらく単体テストということになるだろう(もしくは機能テスト1とかかなあ)。
　で、標準にもよるけど通常は「試験密度」「バグ摘出密度」なんてものが各社標準で定義されている。1ksあたり何件の試験をすること、みたいな。試験項目は通常帳票で管理され、Excelなんかで表形式で作ったりマトリクス形式で作成することが多い。PCLとかMCLなんて言葉は有名だよね。
　この方法のいいところは「試験項目数」が明確であること。これによって単純に客観的に項目の多寡を議論することができる。もちろん、試験項目の粒度によって項目数は著しく増減するが、その水準の是非はレビューで洗われる。
　ユニットテストはどうか、というとこのあたりがまだ「これだ」というのがないんではないか。JUnitを使う場合に

public void testPCL1_1_4() {
}
public void testPCL1_1_5() {
}

　なんかとやる方法もあるかもしれないな。しかしこれは可読性が低い…いずれにせよ、あるユニットテストのコードがあるとして「それは何項目なのよ」というあたりをちゃんと明示しなくてはならない。もしメソッド数と1:1でないのだとすれば、それは従来のExcel表にカラムでも追加して「テストメソッド**でやります」と書くことになるが、これは二重管理というか冗長な感じがする。
　やっぱこの時点でのオススメはメソッドと1:1で何をしているかをExcelにも書いておくのが、重いプロセス標準で戦う人向けすかね?

　と、ここでちょっと話を外してみて、最近このテストケースをふたたび帳票ベースにしようという動きがある。ただし、「テストの自動化」というところは損なわずに、だ。たとえばExcelの表に 事前条件 と 処理 と 事後条件 をうまく書いて、それをプログラムが自動的に処理できるのであれば、それは親和性が高いものになるだろう。
　私が使ったことがあるのは TestCaseTool(http://www5f.biglobe.ne.jp/~webtest/testcasetool/ja/)だが、これはWebのAcceptance Testの自動化なんかをうまく帳票ベースで自動化できそうなエンジンである。このほかにも seasarで S2UnitでExcelを読んで・・・というのももちろん可能だし、Fitnesseもそのひとつだろう。
　これらをExcelであれXMLであれ、そういう「データ的な表現」を行うものにExtractしていくとすれば、試験内容はデータとして表現できなくてはならない。先ほどの例であれば「事前条件」はデータとして表現可能である必要がある。たとえばそれは独自のニーモニックを持つことになるかもしれない。
　この方法は一見スマートだと思うけども、さまざまなテストを実施するにあたりニーモニックに対する要求(表現の要求、なのかな)もエスカレートしてくる。そして気が付けば…あれ?試験項目表にはまるで Javaのソースコードをコピペしたような悲惨な状態が…(想像に難くない)

　とすると、なんかうまい方法はないのか。帳票ドリブンでテストの自動化もできて、しかもちゃんと「テスト項目表」として人間がハンドリングできるものになっているような…これはひょっとして 日本語Mind*1や、「ひまわり」のような日本語記述型処理系をニーモニックに取り込むとうまくいくのではないか！

　とアイデアベースで終わり。日記だから、まあ、いいか。これにちゃんとしたソリューションが出せたら小論文ぐらいにはなるな(笑)

*1:知ってる人いますか??