| make を使った自動テスト |
| トップページ | Unix | Cygwin | Vim | WindowMaker | Zsh | テスト | H.O,K. | curry | 日記 |
|
テストサンプル ソフトウエアのテストに関して, 私の実践を記述します. make を使った自動テストのサンプル 2005.2.11 sakaihdt sakaihdt@d2.dion.ne.jp テストサンプルこの文章はテストサンプルを元に記述しています. テストサンプルは以下から取得して下さい. echo_sample.tar.gz Cygwin上でのテストしか行っていませんが, Unixであればテスト可能だと思います. makeを使った自動テストの概要この文章では, makeを使った自動テストのサンプルと, その説明を記述しています. make を使った自動テストの概要は以下のとおりです.
今回, 自動テストのサンプルとして添付するのは, Unixのechoコマンドもどき [ my_echo ] コマンドの 自動テストです. サンプルプログラムのコンパイル方法bin ディレクトリに移動して make clean all としてください. $ cd bin $ make clean all my_echo プログラムがコンパイルできない場合は, my_echo.sh をリネームして, my_echoを作成してください. $ mv my_echo.sh my_echo $ chmod a+x my_echo サンプルテストの実行方法test ディレクトリに移動して, make とすれば, 自動テストが 実行されます. $ cd test $ make ディレクトリの構成echo_sample/
+bin/ <= プログラムを格納しているディレクトリです.
my_echo.c <= テスト対象のプログラムソース
Makefile <= コンパイル用のMakefile
my_echo.sh <= my_echo.c がコンパイルできなかった場合の予備ファイル
+test/ <= テスト用のディレクトリ
Makefile <= テスト実行のためのMakefile
このMakefileないでテストケースを呼び出している.
testtemplate.mk <= テストケースのテンプレート
+TEST01/ <= テストケース１
Makefile <= テストケース１用のMakefile
cmpstdlog <= テスト結果との比較用のログ
自動テスト前に作成する.
nowstdlog <= テスト実行時に作成されるログ
+TEST02/ <= テストケース２
+TEST03/ <= テストケース３
+TEST04/ <= テストケース４
+TEST05/ <= テストケース５
自動テストの流れtest/ ディレクトリで make を実行すると, Makefile に登録されている テストケースをすべて実行します. (test/Makefile内の TERGET変数) テストケースは, test/ディレクトリのサブディレクトリ毎に作成されています. 各テストケースでは, 以下の処理を行います. 1) 初期化処理テストのタイトル表示と, 前回テスト時のログを削除します. 2) コマンド実行ターゲットのコマンドの実行を行います. コマンドの出力ログと出力ステータスを, ログに保存します. 3) 検証比較用のログと, 今回コマンド実行で作成したログファイルを diff等で, 比較します. コマンドが出力ファイルを作成するような場合は, 出力ファイルも 比較します. diffで単純比較できない場合(バイナリファイルなど), 何らかのツールを使いテキスト情報にコンバートして 日付情報などを削除した後に比較を行います. 4) 終了処理テストの終了を知らせるメッセージを表示します. テストケースがすべて終了したところで, 集計結果を表示します. (test/Makefile内の end:) 比較用のログファイルをどのように作成するか？テストケースのディレクトリ内の 比較用ログは, あらかじめ作成しておく 必要がありますが, このような簡単なプログラムであれば, 手で作成する ことも可能です. しかし, 出力されるログの量が多くなってくると, 人の手で作成することは むづかしくなってきます. そこで, まずテストケース内のMakefileを作成し, 失敗するのをわかりながら, テストケースの実行を行います. $ make テストケースは失敗しますが, 今回行ったテストケースのログは残ります. まず, 予想していた結果かどうかを確認し, ( more nowstdlog ) 今回作成したログを, 比較用のログとして保存します. $ make makecmp (cp -rp nowstdlog cmpstdlog を行っている. ) 次回このテストケースを実施する場合は, 比較用ログが存在しますので, ake とうって, 成功するのを待つだけです. 自動テストの注意点自動化するわけですので, 以下のような注意が必要です.
自動化の利点テストケースが, 2,3個の場合は, 何も問題にならないでしょうが, 機能追加されていくたびに, テストケースは増えていきます. 新たに, 機能を追加して, プログラムソースを修正した場合, 以前の機能が損なわれていないかをチェックするのに, 膨大な時間が費やされるのが常です. 自動テストは, その膨大な時間を少しでも軽減するための仕組み だと考えています. 業務でどう活かすか？新規作成のプログラムに対して, 自動テストを作っておくことは 後々便利です. また, 他人の作ったプログラムの保守でも, 今回紹介した 自動テストは役に立つと思います. たとえば, プログラムの保守を頼まれた場合, クライアントから まず何種類かテストパターン(口頭かもしれませし, 入力データだけかも しれません) をもらうと思うのですが, そのデータを元に, テストケースを作成し, 比較用データも生成しておきます. こうすることで, 機能拡張時に, クライアントから提示されていた テストパターンに関してはデグレードしていない保障ができるわけです. 当然漏れはでてくるので, そのたびにテストケースを追加していきます. その他 テストに関してXUnit (UnitTest)アジャイルな開発でよく取り上げられるのが, XUnit(UnitTest)という ツールです. 単体テスト(特に関数のテスト)をターゲットとする場合, このようなツールを使うの手だと思います. 例： CUnit CppUnit VBUnit RubyUnit WebUnit JUnit 参考： Unit Test/ツールへのリンク集 (オブジェクトクラブ)http://www.objectclub.jp/community/XP-jp/xp_links/ 同じくオブジェクトクラブより XPhttp://www.objectclub.jp/community/XP-jp/xp_relate/xp-faq 日本語訳：「JUnitテスト熱中症：プログラマは、テストを書くのが好きになる」http://www.esm.co.jp/eXtremeProgramming/TestInfected-J.html Amazon.co.jp： 本: eXtreme Programmingテスト技法―http://www.amazon.co.jp/exec/obidos/ASIN/4798101281/250-7300424-2354667 XUnitはテスティングフレームワークです. 非常に強力なツール(テストの成功率／実行時間なども計測できる)なのですが, 既存プログラムにこのようなツールを適用するのは非常に手間がかかります. また, 関数のテストになりますので, 使用言語に大きく左右されます. フリーソフトウェアのテストフリーソフトウェアのソースコードには, テストがついていることがよくあります. ソースコードをダウンロードし, make したあと, $ make test もしくは $ make check などで, 自己テストを行えるようなソフトは結構あります. (gcc, vim, zsh, ruby, perlには実際あります. ) 自動テストの方法は, shellを使っていたり, Perlを使っていたりさまざまですが, 非常に参考になります. 連絡は, sakaihdt@d2.dion.ne.jp までどうぞ. |
| トップページ | Unix | Cygwin | Vim | WindowMaker | Zsh | テスト | H.O,K. | curry | 日記 |