結果

終了時に、テストケースは、状態と、オプションで、なぜテストがそのような状態を報告したかを記述するテキスト形式の理由を報告します。テストプログラムが偽りで、したがって、誤解を招く結果を提供するように、テストケースがその状態を記述するタスクを実際に実行することを、呼び出し側は、保証しなければなりません (例えば、成功を示す結果を提供しますが、プログラムのエラーコードがそうでないと記述している)。

テストケースの指定できる終了状態は、次のうちの 1 つです:

expected_death

テストケースは、突然に終了することを予期します。

expected_exit

テストケースは、きれいに終了することを予期します。

expected_failure

テストケースは、コントローラの致命的な/致命的ではない失敗で終了することを予期します。これが起こるなら、テストプログラムは、成功したエラーコードで終了します。

expected_signal

テストケースは、それを終了させるシグナルを受け取ることを予期します。

expected_timeout

テストケースは、そのタイムアウト以上の長さで実行することを予期します。

passed

テストケースは、成功して実行されました。テストプログラムは、成功したエラーコードで終了します。

skipped

テストケースは、いくつかの必須条件が満たされなかったので、実行することができませんでした。一般的に、必要な状態を満たすためにシステムを調節することによって、解決することができるので、これは、失敗ではありません。これは、常になぜテストがスキップされたか説明するメッセージである 理由 を伴います。テストプログラムは、成功したエラーコードで終了します。

failed

エラーが、テストケースの実行の間に現われました。これは、常になぜテストが失敗したか説明するメッセージである 理由 を伴います。テストプログラムは、失敗のエラーコードで終了します。

‘expected_*’の実用性は、書き込みとのテストケースのとき、が一般的に、プログラミングエラー (別名、バグ) のために起こった既知の失敗を確認する結果となります。期待値が伝えるように試みている不完全な条件が固定されるときはいつでも、テストケースは、‘failed’として報告され、開発者は、その新しい条件と一致するようにそれを調節しなければなりません。

すべての‘expected_*’の結果は、呼び出し側への ヒント としてのみ提供されることに注意することは重要です。呼び出し側は、テストケースが予期された条件のように実際に終了したことを確認しなければなりません。

入力/出力

テストケースは、自由に、それらの stdout(4) と stderr(4) ファイル記述子に望むものはなんでも印刷することができます。実際、それらは、それらの動作に詳しいユーザを保持するために実行するとき、状況情報を印刷するように促進されます。これは、長いテストケースのために特に重要です。

テストケースは、補助のファイルにそれらの結果をログ記録し、その後、それらが含まれている、テストプログラムによって集められます。開発者は、テストケースを実装するために正確な API を使用する限り、これに関して考慮する必要がありません。

テストケースの標準入力は、無条件に‘/dev/zero’に接続されます。

メタデータ

次のリストは、ATF によって内部的に解釈されたすべてのメタデータ特性について記述しています。自由にテストケースの新しい特性を定義し、望むようにそれらを使用できますが、非標準の特性は、‘X-’を前に付けなければなりません。

descr

タイプ: テキスト形式。必須。

テストケースの目的の簡潔なテキスト形式の記述。報告でユーザに表示されます。また、文書化の目的に良いことです。

has.cleanup

タイプ: ブール値。省略可能。

真に設定されるなら、テストケースが、実行のクリーンアップのフェーズに間に、 atf-run(1) によって実行されなければならないクリーンアップルーチンがあることを指定します。この特性は、クリーンアップルーチンがあるテストケースを定義するとき、フレームワークによって自動的に設定されるので、けっして手動によって設定されるべきではありません。

ident

タイプ: テキスト形式。必須。

テストケースの識別子。テストプログラムの内部でユニークでなければなりません、そして記述的でなく、短くあるべきです。

require.arch

タイプ: テキスト形式。省略可能。

アーキテクチャに不一致のためにエラーを引き起こさずに、テストケースを実行することができるアーキテクチャの空白類で区切られたリスト。

require.config

タイプ: テキスト形式。省略可能。

テストケースを実行するために定義されなければならない設定変数の空白類で区切られたリスト。要求される変数のいずれかが定義されていないなら、テストケースは、 スキップ されます。

require.files

タイプ: テキスト形式。省略可能。

テストケースを実行するために存在しなければならない空白類で区切られたファイルのリスト。これらのファイルの名前は、絶対パスでなければなりません。要求されるファイルのいずれかが見つからないなら、テストケースは、 スキップ されます。

require.machine

タイプ: テキスト形式。省略可能。

不一致のマシンタイプのためにエラーを引き起こさずに、テストケースを実行することができるマシンタイプの空白類で区切られたリスト。

require.memory

タイプ: 整数。省略可能。テストによって必要とされる物理的メモリの最小の量を指定します。値は、バイトの量をタイプして読むことを簡単にするために、‘K’, ‘M’, ‘G’または‘T’のようなサイズに接尾辞を持つことができます。

require.progs

タイプ: テキスト形式。省略可能。

テストケースを実行するために存在しなければならない空白類で区切られたプログラムのリスト。これらは、平板な名前として与えることができます、その場合には、それらは、ユーザの PATH または絶対パスとして検索されます。要求されるプログラムのいずれかが見つからないなら、テストケースは、 スキップ されます。

require.user

タイプ: テキスト形式。省略可能。

テストケースを実行するために要求される特権。‘root’またh ‘unprivileged’のうちの 1 つを指定できます。

テストケースが通常で実行され、この特性が‘root’であるなら、テストケースは、 スキップ されます。

テストケースが root として実行され、この特性が‘unprivileged’であるなら、 atf-run(1) は、‘unprivileged-user’設定特性が設定されているなら、自動的に特権を落とします。そうでなければ、テストケースは、 スキップ されます。

timeout

タイプ: 整数。省略可能。デフォルトは、‘300’です。

テストケースが実行することができる時間の最大の量を指定します。それらが不正確にコード化されるか、またはそれらがプログラムの異常な振る舞いをトリガするかのいずれかのために、いくつかのテストがストール (stall) するので、これは、特に役に立ちます。テストプログラムの全体の実行をストール (stall) するために、これらのテストは、ふさわしくありません。

オプションで 0 に設定することができ、その場合に、テストケースには、実行時の制限はありません。これは、非推奨です。

環境

テストケースが実行されるごとに、それらがテストを予期されない条件のために失敗しないことを保証するために、いくつかの環境変数は、通常の値にクリアされるか、または、リセットされます。これらの変数は、次の通りです:

HOME

作業ディレクトリのパスに設定します。

LANG

未定義です。

LC_ALL

未定義です。

LC_COLLATE

未定義です。

LC_CTYPE

未定義です。

LC_MESSAGES

未定義です。

LC_MONETARY

未定義です。

LC_NUMERIC

未定義です。

LC_TIME

未定義です。

TZ

‘UTC’に決めうちされています。

作業ディレクトリ

テストプログラムは、常にテストケースの本体を実行する前に、一時的なディレクトリとそれへのスイッチを作成します。このように、テストケースは、自由にそのカレントディレクトリを修正することができ、実行時のエンジンは、システムからその実行のあらゆるトレースを取り除いて、安全な方法でそれを後でクリーンにすることができます。そうするために、実行時のエンジンは、マウントポイントとクロスせずに、作業ディレクトリの再帰的な削除を実行します。マウントポイントが見つかるなら、ファイルシステムは、(できれば) アンマウントされます。

ファイル作成モードのマスク (umask)

テストケースは、‘0022’のファイル作成モードマスク (umask) で常に実行されます。テストケースのコードは、実行の間に自由にこれを変更することができます。