Go to the first, previous, next, last section, table of contents.


Autotestで一般的なテストスイートを生成する

注意:このセクションでは,この次のリリースの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{testsuite}スクリプト

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*]

Autotestのログ

実行時に,テストスイートはそれ自身の名前に`.log'が後置されている ログファイルを作成し,例えば,@command{testsuite}という名前のテストス イートは`testsuite.log'を作成します.それには多くの情報が含まれ, 通常は管理者が実際に必要とするもの以上ですが,そのためほとんどの場合で 必要とされるすべてのものが含まれます.

command line arguments
コマンドライン引数
残念なことに広く広がっているUnixの非常に悪い習慣は, `CC=my-home-grown-cc ./testsuite'のように,コマンドの前に環境変数 を設定することです.この結果テストスイートは変更を知ることが無く,その ため,(i)それを報告することが不可能で,(ii)連続する実行に対しCC の値を保存することができません(7).Autoconfは全く同じ問題に直面していて,コマンドライン変数での変数定 義を渡すようユーザに依頼することで解決しました.Autotestでもこの規則が 要求されますが,強制する意味はありません.ログにはユーザが変更した変数 の追跡が含まれています.
`ChangeLog'の抜粋
ソースの階層で見つかるすべての`ChangeLog'の先頭の行です.バグがパッ ケージの開発バージョンで報告されるとき,バージョン文字列はユーザがコン パイルしたソースの正確な状態を知るための情報としては十分ではないので, これは特に役に立ちます.もちろんこれは`ChangeLog'の使用方法に依存 します.
ビルドマシン
クロスコンパイル環境でテストスイートを実行するということは,テストスイー トはマシンbuildで実行されますがプログラムはマシンhostで実 行されるという意味があり,簡単な作業ではありません.テストスイートとプ ログラムの両方をhostで実行するのはより簡単ですが,テストスイート の観点からすると,単一の環境変数host = buildは残ります.ロ グにはビルドマシンに関連する情報が含まれていて,それには重要な環境変数 も含まれています.
テストされたプログラム
テストされたプログラムの絶対バスと@option{--version}の答えです (section `testsuite.at'を書くAT_TESTEDを参照してください).
コンフィグレーションのログ
@command{configure}で生成される`config.log'の内容が後置されます. それにはコンフィグレーションフラグとコンフィグレーション自身の詳細な報 告が含まれます.

`testsuite.at'を書く

`testsuite.at'はBourneシェルスクリプトで,特殊なAutotest M4マクロ を使用して作成します.それは,最初の方でAT_INITの呼び出しを含ん でいて,それにテストのためのソースファイルごとにm4_includeの呼 び出しが続きます.それぞれのインクルードファイルや,インクルードファイ ルが使用されていない場合は`testsuite.at'の残りは,テストグループ の連続した手続きが含まれています.それぞれのテストグループは AT_SETUPの呼び出しで始まり,それは任意の数のシェルコマンドや AT_CHECKの呼び出しが含まれていて,AT_CLEANUPの呼び出しで 完結します.

Macro: AT_INIT (@ovar{name})
Autotestを初期化します.パッケージに複数のテストスイートを含める場合, テストスイートにnameを与えることが推奨されます.すべての状況で, テストスイートは常にパッケージ名とバージョンを表示します.それはパッケー ジのバグを報告する(メール)アドレスも継承します.

Macro: AT_TESTED (executables)
それぞれのプログラムのパスと@option{--version}の答を,スペースで分離さ れているリストexecutablesにログをとります.複数回呼び出されると 新しい実行が登録され,言い替えると,一つのプログラムの複数回の登録を危 惧する必要はありません.

Autotestテストスイートは,テストされるプログラムを見つける際に PATHに依存します.これは様々なツールの絶対パスから生成されるも のから保存され,インストールされているプログラムのテストを可能にします. そのため,動作しているプログラムを知ることは,テストスイート自身やその 偶発的な誤使用の問題を理解するために重要です.互換性の問題を簡単に診断 するために,依存している外部のプログラムを登録することも重要です.

Macro: AT_SETUP (test-group-name)
このマクロは関連するテストのグループがすべて同じサブシェルで実行される ように開始します.それは,開始されるテストグループの目的を手短に記述し た数語の単語(30から40文字以下)を保持している,単一の引数を受け入れます.

Macro: AT_KEYWORDS (keywords)
まとまっているテストグループに関連する,スペースで分離されている keywordsのリストです.これでテストスイートの"slices"を実行する ことが可能になります.例えばテストグループの`foo'の機能を行使して いる場合,`AT_KEYWORDS(foo)'を使用することで,これらのテストグルー プを排他的に実行するために`./testsuite -k foo'を実行します.テス トグループのtitleは,AT_KEYWORDSに自動的に保存されます.

テストグループ内で複数回呼び出すことで新しいキーワードを累積します.言 い替えると,テストグループで同じキーワードを複数回登録することを危惧す る必要はありません.

Macro: AT_CLEANUP
現在のテストグループを終了します.

Macro: AT_DATA (file, contents)
入力データのfileを,与えられたcontentsで初期化します.もち ろん,カンマが含まれていることや,見せかけのM4の展開から保護するために, contentsは適切に角カッコで囲む必要があります.内容は行末(EOF)で 終える必要があります.

Macro: AT_CHECK (commands, @dvar{status, `0'}, @ovar{stdout}, @ovar{stderr})
与えられたシェルコマンドcommandsを実行することでテストを実行しま す.これらのコマンドは,期待されるstdoutstderrの内容を生 成しながら,通常のstatusで終えるべきです.commandsが77のス テータスで終了する場合,テストグループ全体が省略されます.

commandsを標準出力にも標準エラー出力にもリダイレクトしては いけません

status,またはstdout,またはstderr`ignore'の 場合,対応する値は調査されません.

stdoutに対する特殊な値`expout'は,commandsの出力がファ イル`expout'の内容であることを期待するという意味があります. stdout`stdout'の場合,commandsの標準出力はファイル `stdout'のテスト以外でも利用可能です.`expout'`stderr' を用いているstderrも同様です.

@command{testsuite}スクリプトの実行

Autotestテストスイートは以下の引数をサポートしています.

`--help'
`-h'
オプションのリストを表示し,正しく終了します.
`--version'
`-V'
テストスイートのバージョンを表示し,正しく終了します.
`--clean'
`-c'
テストスイートが生成したすべてのファイルを削除し終了します.Makefileター ゲットのcleanを意味します.
`--list'
`-l'
すべてのテスト(またはセクションのみ)を,可能なキーワードを含めてリスト アップします.

デフォルトで,すべてのテストはデフォルトの環境変数で,最初は静かに,そ の後で冗長に実行され(または@option{--list}で記述され)ますが,テストの 組の環境変数と冗長さの度合は調整可能です.

`variable=value'
環境変数variablevalueに設定します.デバッグスクリプトと して`FOO=foo ./testsuite'を実行して,その後で異なる環境変数で実行 しないでください. 変数AUTOTEST_PATHPATHに前置するためにテストするパスを 指定します.それは特別に相対パス(`/'で始まらない)を処理します.そ れらは,ビルドしているパッケージのトップレベルから相対的なものと考えら れます.すべてのディレクトリは絶対的になり,最初はビルドツリー のトップレベルで開始され,その後でソースツリーで開始されます. 例えば,`/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に追加されます.
`number'
`number-number'
`number-'
`-number'
明確な意味を持ち一致するテストグループを選択肢に追加します.
`--keywords=keywords'
`-k keywords'
(AT_SETUPAT_KEYWORDSへの引数となる)タイトルやキーワー ドがすべてのカンマで分けられたリストkeywordsのキーワード にマッチするテストグループの選択に追加します. `./testsuite -k autoupdate,FUNC'を実行すると, (`AC_CHECK_FUNC'`AC_FUNC_FNMATCH'などで) `autoupdate'および `FUNC'でタグ付けされているすべての テストを選択しますが,`./testsuite -k autoupdate -k FUNC'`autoupdate'あるいは`FUNC'でタグ付けされているすべて のテストを選択します.
`--errexit'
`-e'
テストが失敗した場合,すぐにテストを中断します.それは@option{--debug} を暗黙に指定します.過去のテストグループをクリーンアップし,デバッグス クリプトを生成し,ログは停止されます.このオプションは,すべてのテスト スイートに対して意味があり,それは生成されるデバッグスクリプトに対して は実際には意味がありません.
`--verbose'
`-v'
行なっているものの詳細な出力でより冗長なものにします.これはデバッグス クリプトに対してデフォルトです.
`--debug'
`-d'
テストグループを実行した後でファイルを削除しません -- しかし,それら は実行前には削除され,そのためこのオプションの使用は,複数のテストグルー プを実行するとき問題ありません.デバッグスクリプトを作成しません.ログ は行なわれません(おそらく存在している既存の完全なログファイルを保持す るためです).これはデバッグスクリプトに対してデフォルトです.
`--trace'
`-x'
テストグループのシェルの追跡を開始します.

@command{testsuite}スクリプトの作成

Autotestを動作に入れるため,コンフィグレーションと`Makefile'のか らくりで必要になるものもあります.少なくともパッケージで深いまたは浅い 階層を使用している場合,すべてのテストとその`Makefile'を格納する ディレクトリの名前として,`tests/'を使用することを推奨します.行 なうことの調査リストは以下のようになります.

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.