注意:このセクションでは,この次のリリースのAutoconfの一部となっ ている,実験的な機能を記述しています.我々はAutotestが安定していること を信じていますが,このドキュメントでは将来変更される可能性があるインター フェースを記述しています.Autoconfのメーリングリストを購読しないまま Autotestに依存することはやめてください.
移植性の高いプロジェクトで,テストスイートを実行するために移植性のない ツールに依存していることは,矛盾しています.Autoconf自身がこの問題の典 型です.2.13までは完全な移植性を目的としていましたが,そのテストスイー トはDeja@acronym{GNU}を使用していて,それは高品質で複雑なテストフレー ムワークですが,Unixシステムの標準からかけ離れていました.悪いことに, ほとんどの壊れやすいプラットフォームが無いことがよくあり,そのプラット フォームがAutoconfを苦しめ,欠陥を提示していることがほとんどでした.
この問題を回避するために,パッケージ管理者の多くは,その出力が終了ステー タスとなる,つまりテストが成功するまたは失敗するといった,単純なシェル スクリプトをベースに,独自のテストフレームワークを開発してきました.さ らに,これらのテストのほとんどは,共通のパターン,重複している大量のコー ドの結果,退屈な管理などを共有しています.
以下はAutoconfが生まれた理由と全く同じですが,Autotestは,M4マクロを基 本として移植性の高いシェルスクリプトを構築するテストスイートを生成する フレームワークを提供しています.スイート自身は,バグの報告で中断するこ とを限りなく少なくし,自動的なログ生成と追跡機能を備えていて,単純なタ イミングでバグは報告されます.
Autoconf自身はAutotestを何年も使用していて,テストスイートとバグの報告 の強さをかなり改善しているattestを実行しています.Autotestの生成 物を使用していることが知られている,Bison,Free Recode,Free Wdiff, @acronym{GNU} Tar といったそれ以外のプロジェクトでは,それぞれ異なるニー ズがあり,一般的なテストフレームワークとしてのAutotestにのんびりと磨き をかけていました.
それにもかかわらず,Deja@acronym{GNU}と比較して,Autotestは対話的なテ ストツールとしては不十分で,それがおそらく主な制限事項となっています.
Autotestを使用してテストスイートや評価スイートを生成することは簡単です. 評価スイート全体は,@command{autom4te}で処理されるファイルに保持されて いて,それ自身は配布物から得られるスタンドアローンのBourneシェルスクリ プトを生成するために,@acronym{GNU} M4の環境下で使用されます. @command{autom4te}も@acronym{GNU} M4もインストールしているエンドユーザ は不要です.
評価スイートのそれぞれのテストは,テストグループの一部にすべきです. テストグループ(test group)は,通常はグループのテストの一つがデー タファイルを作成し,それ以降のテストで同じグループのテストがそれを読み 込むために,お互いに実行される必要がある混合テストの,連続した手続きに なっています.テストグループごとの数個のテストのみを維持する方がより良 く,テストグループごとに一つのテストのみを維持することが可能な場合,そ れは理想的です.
最も単純なパッケージ以外のすべてのものに対して,`testsuite.at'の ようなファイルは,別々のファイルにした方が管理しやすいことも多いので, すべてのテストのソースを完全に保持しているわけではありません.これらの 個別のファイルのそれぞれは,単一のテストグループや,パッケージの共通の 機能をすべて提示しているテストグループの連続したものを維持しています. そのような場合は,ファイル`testsuite.at'は評価スイート全体の初期 化のみを行ない,他のすべてのテストファイルに対して含める文をリストアッ プする前に,要素が健全かどうかを調査するときもあります.特殊なファイル `package.m4'はパッケージの識別子を含んでいて,見つかった場合は自 動的にインクルードされます.
Autotestが生成する評価スクリプトは,慣習で@command{testsuite}から呼び 出されます.実行時には,@command{testsuite}はそれぞれのテストグループ を順番に実行し,テストごとにその特定のテストが成功したか失敗したかを告 げる概要を表示する一行を生成します.すべてのテストの終りに,数を集約し て出力します.テストが失敗した場合,失敗したそれぞれのテストグループに 対してデバッグスクリプトが自動的に生成されます.これらのデバッグスクリ プトは`testsuite.nn'と命名され,nnはテストグループの 順番を示す数です.理想的な状況では,テストは失敗しませんし,従ってデバッ グスクリプトは評価からは生成されません.
失敗したテストに対する自動的に生成されるデバッグスクリプトには,バグを 簡単に追跡するという目的があります.
評価スイートの個別のテストがコンフィグレーションスクリプトからの情報を
入手する必要が生じることも,実験段階ではよくあります.すべての評価スイー
トで共通なこの情報が,AC_CONFIG_TESTDIR
で自動的に生成されるファ
イル`atconfig'で提供されることもあります.テスト環境で特別に必要
となるコンフィグレーションの情報に対し,AC_CONFIG_FILES
で実際に
作成されるように,`atlocal.in'という名前の追加ファイルを準備して
もかまいません.コンフィグレーションのプロセスで,`atconfig'と
`atlocal' は二つの入力ファイルから作成され,これら二つの生成され
たファイルは,自動的に`testsuite'スクリプトで読み込まれます.
ファイル間の関係を表示する図は以下のようになります.
配布するソフトウェアパッケージの準備に使用されるファイルです.
subfile-1.at ->. ... \ subfile-i.at ---->-- testsuite.at -->. ... / \ subfile-n.at ->' >-- autom4te* -->testsuite / [package.m4] ->'
ソフトウェアパッケージのコンフィグレーションで使用されるファイルです.
.--> atconfig / [atlocal.in] --> config.status* --< \ `--> [atlocal]
テストスイートを実行中に作成されるファイルです.
atconfig -->. .--> testsuite.log \ / >-- testsuite* --< / \ [atlocal] ->' `--> [testsuite.nn*]
実行時に,テストスイートはそれ自身の名前に`.log'が後置されている ログファイルを作成し,例えば,@command{testsuite}という名前のテストス イートは`testsuite.log'を作成します.それには多くの情報が含まれ, 通常は管理者が実際に必要とするもの以上ですが,そのためほとんどの場合で 必要とされるすべてのものが含まれます.
CC
の値を保存することができません(7).Autoconfは全く同じ問題に直面していて,コマンドライン変数での変数定
義を渡すようユーザに依頼することで解決しました.Autotestでもこの規則が
要求されますが,強制する意味はありません.ログにはユーザが変更した変数
の追跡が含まれています.
AT_TESTED
を参照してください).
`testsuite.at'はBourneシェルスクリプトで,特殊なAutotest M4マクロ
を使用して作成します.それは,最初の方でAT_INIT
の呼び出しを含ん
でいて,それにテストのためのソースファイルごとにm4_include
の呼
び出しが続きます.それぞれのインクルードファイルや,インクルードファイ
ルが使用されていない場合は`testsuite.at'の残りは,テストグループ
の連続した手続きが含まれています.それぞれのテストグループは
AT_SETUP
の呼び出しで始まり,それは任意の数のシェルコマンドや
AT_CHECK
の呼び出しが含まれていて,AT_CLEANUP
の呼び出しで
完結します.
Autotestテストスイートは,テストされるプログラムを見つける際に
PATH
に依存します.これは様々なツールの絶対パスから生成されるも
のから保存され,インストールされているプログラムのテストを可能にします.
そのため,動作しているプログラムを知ることは,テストスイート自身やその
偶発的な誤使用の問題を理解するために重要です.互換性の問題を簡単に診断
するために,依存している外部のプログラムを登録することも重要です.
AT_KEYWORDS
に自動的に保存されます.
テストグループ内で複数回呼び出すことで新しいキーワードを累積します.言 い替えると,テストグループで同じキーワードを複数回登録することを危惧す る必要はありません.
commandsを標準出力にも標準エラー出力にもリダイレクトしては いけません.
status,またはstdout,またはstderrが`ignore'の 場合,対応する値は調査されません.
stdoutに対する特殊な値`expout'は,commandsの出力がファ イル`expout'の内容であることを期待するという意味があります. stdoutが`stdout'の場合,commandsの標準出力はファイル `stdout'のテスト以外でも利用可能です.`expout'と `stderr' を用いているstderrも同様です.
Autotestテストスイートは以下の引数をサポートしています.
clean
を意味します.
デフォルトで,すべてのテストはデフォルトの環境変数で,最初は静かに,そ の後で冗長に実行され(または@option{--list}で記述され)ますが,テストの 組の環境変数と冗長さの度合は調整可能です.
AUTOTEST_PATH
はPATH
に前置するためにテストするパスを
指定します.それは特別に相対パス(`/'で始まらない)を処理します.そ
れらは,ビルドしているパッケージのトップレベルから相対的なものと考えら
れます.すべてのディレクトリは絶対的になり,最初はビルドツリー
のトップレベルで開始され,その後でソースツリーで開始されます.
例えば,`/tmp/foo'でビルドされている`/src/foo-1.0'のソースパッ
ケージの`./testsuite AUTOTEST_PATH=tests:bin'は,結果として
`/tmp/foo/tests:/tmp/foo/bin'になり,そして
`/src/foo-1.0/tests:/src/foo-1.0/bin'がPATH
に追加されます.
AT_SETUP
やAT_KEYWORDS
への引数となる)タイトルやキーワー
ドがすべてのカンマで分けられたリストkeywordsのキーワード
にマッチするテストグループの選択に追加します.
`./testsuite -k autoupdate,FUNC'を実行すると,
(`AC_CHECK_FUNC'や`AC_FUNC_FNMATCH'などで)
`autoupdate'および `FUNC'でタグ付けされているすべての
テストを選択しますが,`./testsuite -k autoupdate -k FUNC'は
`autoupdate'あるいは`FUNC'でタグ付けされているすべて
のテストを選択します.
Autotestを動作に入れるため,コンフィグレーションと`Makefile'のか らくりで必要になるものもあります.少なくともパッケージで深いまたは浅い 階層を使用している場合,すべてのテストとその`Makefile'を格納する ディレクトリの名前として,`tests/'を使用することを推奨します.行 なうことの調査リストは以下のようになります.
AT_PACKAGE_STRING
と,
バグレポートを送るアドレスAT_PACKAGE_BUGREPORT
を定義する必要が
あります.完全性の目的で,AT_PACKAGE_NAME
,
AT_PACKAGE_TARNAME
,そしてAT_PACKAGE_VERSION
を定義するこ
とも提案します.これらの変数の記述はSee section @command{configure}の初期化. 我々
は以下のようなMakefileの断片を提案します.
$(srcdir)/package.m4: $(top_srcdir)/configure.ac { \ echo '# Signature of the current package.'; \ echo 'm4_define([AT_PACKAGE_NAME], [@PACKAGE_NAME@])'; \ echo 'm4_define([AT_PACKAGE_TARNAME], [@PACKAGE_TARNAME@])'; \ echo 'm4_define([AT_PACKAGE_VERSION], [@PACKAGE_VERSION@])'; \ echo 'm4_define([AT_PACKAGE_STRING], [@PACKAGE_STRING@])'; \ echo 'm4_define([AT_PACKAGE_BUGREPORT], [@PACKAGE_BUGREPORT@])'; \ } >$(srcdir)/package.m4`package.m4'を配布していることと,それをソースの階層に書いている ことを確かめてください.テストスイートは配布する必要があります!
AC_CONFIG_TESTDIR
の呼び出し.
AUTOTEST_PATH
をtest-pathに設定します(see section @command{testsuite}スクリプトの実行).
AC_CONFIG_FILES
コマンドが
`tests/atlocal'での代入を確実に含むよう,適切に
`configure.ac' に書いてください.
Automakeを用いると,評価スイートで`make check'をリンクする方法の 最小限の例は以下のようになります.
EXTRA_DIST = testsuite.at testsuite TESTSUITE = $(srcdir)/testsuite check-local: atconfig atlocal $(TESTSUITE) $(SHELL) $(TESTSUITE) AUTOTEST = $(AUTOM4TE) --language=autotest $(TESTSUITE): $(srcdir)/testsuite.at $(AUTOTEST) -I $(srcdir) $@.at -o $@.tmp mv $@.tmp $@
依存性,すなわち`testsuite.at'を含んでいるファイルのリストを,明 示的にリストアップしたいかもしれません.
厳密にAutoconfを用いると,以下のような行を追加する必要があるかもしれま せん.
subdir = tests atconfig: $(top_builddir)/config.status cd $(top_builddir) && \ $(SHELL) ./config.status $(subdir)/$@ atlocal: $(srcdir)/atlocal.in $(top_builddir)/config.status cd $(top_builddir) && \ $(SHELL) ./config.status $(subdir)/$@
そして,`atconfig.in'と$(EXTRA_DIST)
を配布物されるように管
理する必要があるかもしれません.
Go to the first, previous, next, last section, table of contents.