今日の役に立たない一言 - Today’s Trifle! -

古い記事ではさまざまなテーマを書いていますが、2007年以降はプログラミング関連の話がほとんどです。

自動テストツールを使おう

以前も同じようなことを書いているけど、補足的な意味でもう一度。
自動テストツール(WinRunner)を導入し、テストを少しずつ追加している。テストを作るのも簡単じゃないから少しずつしかできないのよ。でも、自動テストツールはすぐにでも導入する価値がある。なぜそう思うのか、思うままに書いてみる。
WinRunnerでテストを作るのってとっても創造的な作業。WinRunnerの記録スイッチをONにして画面を操作すると、TSLという専用のスクリプトにリアルタイムに落とされていく。そのままではスクリプトとしていまいちなので、プログラマの立場でスクリプトを変更する。WinRunnerはスクリプトに従ってターゲットアプリケーションを動かしてくれる。つまりターゲットアプリケーションを動かすためのプログラムを書いているってわけ。TSLでスクリプトを書けばそのとおりにテストができるってのはプログラマにとっては喜ばしいことだ。
なんといっても、一旦テストを書いてしまえば、あとは勝手にWinRunnerが何度でもやり直してくれるってのが嬉しい。バグを再現させるために、手作業で同じテストを何度も繰り返し、バグを修正したらまた同じ手作業で動作確認をやんなきゃいかんという、まるで拷問のような作業からプログラマを解放してくれる。
同じことをパラメータを変えながら繰り返し行うことだってできる。画面での入力フィールドとそこに入力する値を Excel の表に書いておくと、表に従って全テストをやってくれる。もちろん、それなりのスクリプトを書かなきゃ動いてくれない。でも、考えてみてよ。延々と表に書かれたテストパターンを手作業でやるなんて考えただけでもぞっとする(世の中にはそういう作業が好きな人もいるかもしれんが)。だけど、表からの入力をもとにWinRunnerを動かすためのスクリプトを考えるのは、プログラマだったらまったく苦にならない(よね?)。
というわけで、この手の機能テストツールはとってもオススメ。別にWinRunnerじゃなくったってかまわない。でも、スクリプトの書きやすさは大切だろうから、そこを頭においてプロダクトを評価するとよかろうと思う*1。導入してしまえば、プログラマにとってイヤな仕事を、何度でもだまってやってくれる良きパートナーになってくれる。

*1:WinRunnerを選択した理由はここらへんに書いたとおりで、他のプロダクトと比較する以前の問題で、実質的に他の選択肢がなかった。相手がJavaじゃなきゃもっといろんな選択肢があるのをお忘れなく。