百科事典をテストする

問題を報告する ソースを表示 夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

テスト実行環境の完全な仕様。

背景

Bazel BUILD 言語には、自動化ツールを定義するために使用できるルールが含まれています。 テスト プログラムを多数の言語で提供しています。

テストは bazel test を使用して実行されます。

ユーザーはテストバイナリを直接実行することもできます。こうした行為は許可されていますが、支持されているわけではありません。 以下に説明する要件を遵守するものではありません。

テストは密閉型である必要があります。つまり、特定のリソースにのみアクセスする必要があります。 依存関係が宣言されます。テストが密閉型でなければ 再現性のある結果が得られませんたとえば 犯人発見のための重大な問題（テストを破った変更の特定） リリース エンジニアリングの監査可能性、テストのリソース分離（自動 サーバーを DDoS 攻撃すべきではないテストもあります。これは、たまたまサーバーと通信して 。

目的

このページの目標は、Google Compute Engine のランタイム環境を Bazel テストで想定される動作を再現しました。また、テストに関する要件も課されます。 ビルドシステムを定義します。

テスト環境の仕様により、テスト作成者は テスト インフラストラクチャでより自由な動作を実現できます。 実装に変更を加えます。仕様では、いくつかの穴を締めて 適切に密閉されていない場合でも多くのテストに合格できる 決定的、リエントラントです。

このページは規範的で信頼できるものであることを意図しています。もし テストランナーの仕様と実装された動作が一致しない場合、 指定が優先されます。

提案された仕様

キーワードは、「しなければならない」、「してはならない」、「必須である」、「すべきである」、「すべきである」、「すべきである」、「すべきである」、 「すべきでないこと」、「推奨」、「しても構いません」、「任意」は、 IETF RFC 2119 をご覧ください。

テストの目的

Bazel テストの目的は、ソースファイルのプロパティを確認することです。 確認できます。（このページの「ソースファイル」には、テストデータ、 サンプル出力、バージョン管理下にあるものなど）です。あるユーザーが 維持が期待される不変条件をアサートできます。その他のユーザー 後でテストを実行して、不変条件が壊れているかどうかを確認します。もし テストがソースファイル以外の変数に依存している場合（密閉型ではない）、その値は 後者のユーザーは自分の変更に誤りがあったことを確認できないため、リスクが軽減されます。 停止したとき。

したがって、テストの結果は次の条件のみに依存する必要があります。

  • テストで依存関係が宣言されているソースファイル
  • テストで依存関係が宣言されているビルドシステムのプロダクト
  • テストランナーによって一定の動作が保証されるリソース

現時点では、このような動作は適用されません。ただし、テストランナーは 当該措置を追加する権利があります。

ビルドシステムの役割

テストルールはバイナリルールと類似しており、各ルールで実行可能ファイルを生成する必要がある 。一部の言語では、これはスタブ プログラムであり、 言語固有のハーネスをテストすることをおすすめします。テストルールでは、 出力です。テストランナーは、プライマリ テスト実行可能ファイルに加えて、 runfiles のマニフェスト、つまり入力ファイルを利用できるようにする必要がある 実行時にテストに提供され、場合によってはタイプ、サイズ、 テストのタグです。

ビルドシステムは、ランファイルを使用してコードやデータを配信できます。（ 最適化として使用して、各テストバイナリのサイズを （ダイナミック リンクを使用するなど）。ビルドシステム 生成された実行可能ファイルが、runfile を介してこれらのファイルを 絶対参照をハードコードするのではなく、テストランナーが提供する ソースツリーまたは出力ツリー内の特定の位置に配置されます。

テストランナーのロール

テストランナーの観点から見ると、各テストは execve() で呼び出されます。テストを実行する方法は他にもあります。たとえば IDE では Java テストをプロセス内で実行できます。しかし、結果 プロセスが信頼できるものと見なされなければなりません。条件 テストプロセスは完了するまで実行され、終了コードで正常に終了します。 テストは合格です。その他の結果はテストの不合格と見なされます。イン 特に、文字列 PASS または FAIL のいずれかを stdout に書き込んでも テストランナーに通知されます。

テストの実行に時間がかかりすぎた場合、なんらかのリソース上限を超えた場合、または 禁止されている動作を検出した場合は、テストを強制終了し、 実行は失敗として処理されますランナーは、次の時間が経過するとテストの合格を報告してはならない テストプロセスまたはその子にシグナルを送信する

（個々のメソッドやテストではなく）テスト ターゲット全体には、 完了するまでにかかる時間です。テストの制限時間は、 timeout 属性に基づく を次の表に示します。

timeout 制限時間（秒）
short 60
中 300
long 900
永遠 3600

タイムアウトを明示的に指定していないテストでは、 テストの size を次のように変更します。

サイズ 暗黙のタイムアウト ラベル
小 short
中 中
大 long
膨大な 永遠

「大」明示的なタイムアウト設定がないテストには、900 が割り当てられる 実行に時間がかかります。「ミディアム」タイムアウトを「short」に設定してテストする60 日割り当てられ 秒です。

timeout とは異なり、size は、予想されるピーク時の使用量も決定します。 他のリソース（RAM など）も保持する必要があります。詳細は、 一般的な定義。

size ラベルと timeout ラベルの組み合わせはすべて正しいため、「非常に大きい」テスト タイムアウトを「short」として宣言できます。おそらく、生成 AI によって 恐ろしいことがすぐに見つかる

テストは、タイムアウトに関係なく任意の速度で返される場合があります。テストにペナルティはない 過剰なタイムアウトが発生しますが、警告が発行されることがあります。 通常は、不具合が発生することなく、タイムアウトをできるだけ厳しく設定します。

テストのタイムアウトは、次の場合に --test_timeout bazel フラグでオーバーライドできます。 手動で実行する場合です。「 --test_timeout の値は秒単位です。例: --test_timeout=120 テストのタイムアウトを 2 分に設定します。

次に示すように、テスト タイムアウトの推奨下限も存在します。

timeout 最小時間（秒）
short 0
中 30
long 300
永遠 900

たとえば「moderate」オプションが5.5 秒でテストが完了するので、timeout = "short" または size = "small" の設定を検討してください。bazel --test_verbose_timeout_warnings の使用 コマンドライン オプションを使用すると、指定したサイズが大きすぎるテストが表示されます。

テストサイズとタイムアウトは、 こちらをご覧ください。条件 指定しない場合、テストのサイズはデフォルトで「medium」になります。

テストのメインプロセスが終了しても、その子プロセスの一部が実行中の場合、 テストランナーは実行が完了したと見なし、成功または メインプロセスから観測された終了コードに基づいて、テストランナー 不要なプロセスを強制終了する場合があります。この方法でテストでプロセスをリークしてはなりません。

テストのシャーディング

テストは、テストのシャーディングによって並列化できます。詳しくは、 --test_sharding_strategy および shard_count が テストのシャーディングを有効にします。シャーディングを有効にすると、テストランナーが 1 回起動 シャードあたり約 100 倍です環境変数 TEST_TOTAL_SHARDS シャードの数、TEST_SHARD_INDEX が 0 から始まるシャード インデックス。ランナーはこの情報を使用して、 たとえば、ラウンドロビン戦略を使用できます。すべてのテストランナーがサポートしているわけではない 説明します。ランナーがシャーディングをサポートしている場合、 ファイルの更新日時を TEST_SHARD_STATUS_FILE。それ以外の場合 --incompatible_check_sharding_support 有効になっている場合、シャーディングされている Bazel はテストに失敗します。

初期条件

テストの実行時、テストランナーは特定の初期状態を あります。

テストランナーは、テスト実行ファイルへのパスを指定して各テストを呼び出す必要があります。 argv[0]。このパスは、テストの現在のディレクトリの下の相対パスにする必要があります （runfiles ツリー内にあります。以下を参照）。テストランナーは ユーザーが明示的に要求しない限り、他の引数はテストに渡されません。

初期の環境ブロックは次のように構成します。

変数 値 ステータス
HOME $TEST_TMPDIR の値 推奨
LANG 未設定 必須
LANGUAGE 未設定 必須
LC_ALL 未設定 必須
LC_COLLATE 未設定 必須
LC_CTYPE 未設定 必須
LC_MESSAGES 未設定 必須
LC_MONETARY 未設定 必須
LC_NUMERIC 未設定 必須
LC_TIME 未設定 必須
LD_LIBRARY_PATH 共有ライブラリを含むディレクトリをコロンで区切ったリスト 省略可
JAVA_RUNFILES $TEST_SRCDIR の値 廃止
LOGNAME $USER の値 必須
PATH /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:. 推奨
PWD $TEST_SRCDIR/workspace-name 推奨
SHLVL 2 推奨
TEST_INFRASTRUCTURE_FAILURE_FILE 書き込み可能なディレクトリにある非公開ファイルへの絶対パス（このファイルは、 テストで生じたエラーを報告する目的でのみ使用してください。 不安定な障害を報告するための一般的なメカニズムではなく、 含まれています。この文脈において、テスト インフラストラクチャとは または、テスト固有ではないものの、テストが失敗する原因となる可能性のあるライブラリ 防ぐことができます。1 行目は、テスト用インフラストラクチャの名前 2 つ目のコンポーネントは人が読める形式で エラーの説明が返されます。余分な行は無視されます）。 省略可
TEST_LOGSPLITTER_OUTPUT_FILE 書き込み可能なディレクトリ（書き込み可能なディレクトリ）内のプライベート ファイルへの絶対パス Logsplitter protobuffer ログ） 省略可
TEST_PREMATURE_EXIT_FILE 書き込み可能なディレクトリにあるプライベート ファイルへの絶対パス（ exit() への呼び出しのキャッチ） 省略可
TEST_RANDOM_SEED --runs_per_test オプションを使用すると、 TEST_RANDOM_SEED が run number に設定されている （1 から始まります）。 省略可
TEST_RUN_NUMBER --runs_per_test オプションを使用すると、 TEST_RUN_NUMBER が run number に設定されている （1 から始まります）。 省略可
TEST_TARGET テスト対象のターゲットの名前 省略可
TEST_SIZE テスト size 省略可
TEST_TIMEOUT テスト timeout（秒単位） 省略可
TEST_SHARD_INDEX シャード インデックス（sharding が使用されている場合） 省略可
TEST_SHARD_STATUS_FILE sharding のサポートを示すために接触するファイルのパス 省略可
TEST_SRCDIR runfiles ツリーのベースへの絶対パス 必須
TEST_TOTAL_SHARDS 合計 shard count sharding が使用されている場合 省略可
TEST_TMPDIR 書き込み可能な非公開ディレクトリへの絶対パス 必須
TEST_WORKSPACE ローカル リポジトリのワークスペース名 省略可
TEST_UNDECLARED_OUTPUTS_DIR 書き込み可能なプライベート ディレクトリへの絶対パス（宣言されていない書き込みを行うために使用 テスト出力）。プロジェクトに書き込まれた TEST_UNDECLARED_OUTPUTS_DIR ディレクトリが圧縮され、 次のフォルダの outputs.zip ファイルに追加 bazel-testlogs。 省略可
TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR 書き込み可能なプライベート ディレクトリへの絶対パス（宣言されていない書き込みを行うために使用 テスト出力アノテーション .part および .pb ファイル）。 省略可
TEST_WARNINGS_OUTPUT_FILE 書き込み可能なディレクトリ（書き込み可能なディレクトリ）内のプライベート ファイルへの絶対パス テスト ターゲットの警告） 省略可
TESTBRIDGE_TEST_ONLY 値 --test_filter （指定されている場合） 省略可
TZ UTC 必須
USER getpwuid(getuid())->pw_name の値 必須
XML_OUTPUT_FILE テスト アクションがテスト結果の XML 出力ファイルを書き込む場所。 それ以外の場合、Bazel はテストログをラップしたデフォルトの XML 出力ファイルを生成します テストアクションの一部として追加できますXML スキーマは、 JUnit テスト結果のスキーマ。 省略可
BAZEL_TEST テスト実行可能ファイルが bazel test によって実行されていることを示します 必須

環境には、追加のエントリが含まれている場合があります。テストは、実際の依存関係や 上記以外の環境変数の有無、値。

最初の作業ディレクトリは $TEST_SRCDIR/$TEST_WORKSPACE とします。

現在のプロセス ID、プロセス グループ ID、セッション ID、親プロセス ID は、 指定されていません。プロセスは、プロセスグループのリーダーまたはセッションであっても、なくてもかまいません。 います。プロセスに制御端子がある場合とない場合がある。このプロセスは 子プロセスがゼロ個以上で、実行されていない、または未処理の子プロセスが存在する。このプロセスでは、 複数のスレッドを持たせる必要があります。

ファイル記述子 0（stdin）は読み取り用にオープンされますが、アタッチされるもの は指定されていません。テストで読み取ってはなりません。ファイル記述子 1（stdout）と 2 （stderr）は書面で公開しますが、添付されるものは 指定されていません。ターミナル、パイプ、通常のファイルなど、任意の 定義できます。開いているファイル テーブルのエントリを共有する （つまり、個別にシークすることはできません）。テストは Pod 内で 記述できます。

最初の umask は 022 または 027 にします。

アラームまたはインターバルタイマーは、保留状態になりません。

ブロックされたシグナルの初期マスクは空とします。すべてのシグナルを できます。

初期リソース制限（ソフトとハードの両方）は次のように設定する必要があります。

リソース 上限
RLIMIT_AS 無制限
RLIMIT_CORE 指定なし
RLIMIT_CPU 無制限
RLIMIT_DATA 無制限
RLIMIT_FSIZE 無制限
RLIMIT_LOCKS 無制限
RLIMIT_MEMLOCK 無制限
RLIMIT_MSGQUEUE 指定なし
RLIMIT_NICE 指定なし
RLIMIT_NOFILE 1,024 以上
RLIMIT_NPROC 指定なし
RLIMIT_RSS 無制限
RLIMIT_RTPRIO 指定なし
RLIMIT_SIGPENDING 指定なし
RLIMIT_STACK 無制限、または 2,044 KB <= rlim <= 8,192 KB

初期プロセス時間（times() によって返される）とリソース使用率 （getrusage() によって返される）は指定されません。

最初のスケジューリング ポリシーと優先度は指定されていません。

ホストシステムの役割

テストを直接制御できるユーザー コンテキストの側面に加え、 テストを実行するオペレーティング システムは、 プロパティを設定する必要があります。

ファイルシステム

テストで観測されるルート ディレクトリは、実際のルート ディレクトリである場合もあれば、そうでない場合もあります。

/proc をマウントします。

すべてのビルドツールは、SDK によって使用される /usr 配下の絶対パスに存在する ローカルにインストールできます。

/home で始まるパスは使用できない場合があります。テストでアクセスすべきでないもの 制限します。

/tmp は書き込み可能ですが、テストではこれらのパスの使用を避ける必要があります。

テストでは、排他的なリソースに対して一定のパスが使用可能であると想定してはいけません。 あります。

テストでは、マウントされたファイルシステムに対して atime が有効になっていることを前提としないでください。

ユーザーとグループ

ユーザー root、nobody、unittest が存在していなければなりません。グループのルート、nobody、 eng が存在しなければなりません。

テストは root 以外のユーザーとして実行する必要があります。実質のユーザー ID と有効なユーザー ID は、 等しいグループ ID についても同様です。これに加えて、現在のユーザー ID、グループ ID、 ユーザー名、グループ名は指定されていません補助グループ ID のセットは、 指定されていません。

現在のユーザー ID とグループ ID には、対応する名前が必要です。名前には、 getpwuid() と getgrgid() で取得します。同じことが 補助グループ ID を指定します。

現在のユーザーにはホーム ディレクトリが必要です。書き込みできない可能性があります。テストは 書き込みは試行されません。

ネットワーキング

ホスト名が指定されていません。ドットを含む場合と含まない場合があります。問題の解決 hostname には現在のホストの IP アドレスを指定する必要があります。ホスト名のカットの解決 機能します。ホスト名 localhost を解決する必要があります。

その他のリソース

テストには少なくとも 1 つの CPU コアが付与されます。他のフォーマットを利用できる可能性はありますが、 保証されています。このコアのその他のパフォーマンス要素は指定されていません。Google Chat では タグを追加して CPU コア数を増やします。 &quot;cpu:n&quot;（n は正の数）をテストルールに渡します。マシンのメモリ容量が CPU コアの合計数がリクエストした値よりも少ない場合でも、Bazel はテストを実行します。テストで シャーディングでは、各シャードが CPU 使用率を 必要があります。

テストでサブプロセスを作成できますが、プロセスグループまたはセッションを作成できません。

テストで使用できる入力ファイルの数には上限があります。この上限は 変更される場合がありますが、現時点では数万の入力の範囲です。

日時

現在の日時は指定されていません。システムのタイムゾーンが指定されていません。

X Windows は、利用できる場合と利用できない場合があります。X サーバーを必要とするテストを開始する必要がある Xvfb。

ファイル システムの操作をテストする

テスト環境変数で指定されたすべてのファイルパスは、 ローカル ファイルシステム（特に指定しない限り）が使用されます。

テストでは、terraform plan または terraform apply で指定された $TEST_TMPDIR と $TEST_UNDECLARED_OUTPUTS_DIR（設定されている場合）。

これらのディレクトリは、最初は空です。

テストで、これらのディレクトリの削除、chmod、その他の変更を行ってはいけません。

これらのディレクトリはシンボリック リンクの場合があります。

$TEST_TMPDIR/. のファイルシステム タイプは未指定のままです。

テストでは、.part ファイルを $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR: 宣言されていない出力ファイルにアノテーションを付けます。

まれに、テストで /tmp にファイルの作成が強制されることがあります。たとえば Unix ドメイン ソケットのパス長の制限 通常、/tmp の下にソケットを作成する必要があります。Bazel は次の操作を行えません。 そのようなファイルを追跡するテスト自体は密閉型になるように注意し、一意の 他の、同時に実行するテストや非テスト モードと競合しないように、 /tmp に作成したファイルのクリーンアップを行います。

一般的なテスト フレームワークには、次のようなものがあります。 JUnit4 TemporaryFolder TempDir に移動すると、 独自の方法で /tmp の下に一時ディレクトリを作成できます。このテストは フレームワークには /tmp 内のファイルをクリーンアップする機能が含まれているため、 TEST_TMPDIR の外部にファイルを作成しても問題ありません。

テストは、runfiles メカニズムなど、Terraform のその他の部分を通じて入力にアクセスする必要があります。 入力ファイルを作成することを目的とする実行環境 できます。

テストでは、ビルドシステムから推定されるパスで、ビルドシステムの他の出力にアクセスすることはできません。 実行可能なファイルの場所を指定します

runfiles ツリーに通常のファイル、シンボリック ファイル、 リンク、それらの組み合わせです。runfiles ツリーにディレクトリへのシンボリック リンクが含まれる場合があります。 テストでは、実行ファイル内の .. コンポーネントを含むパスを使用しない 表示されます。

runfiles ツリー内にディレクトリ、ファイル、シンボリック リンクがない（ シンボリック リンクをトラバースする）は、書き込み可能でなければなりません。（最初の動作は、 ディレクトリは書き込み可能にしないでください）。テストでは、インフラストラクチャのいかなる部分も runfile が書き込み可能であるか、または現在のユーザーが所有していること（たとえば、chmod と chgrp は 失敗します）。

runfiles ツリー（シンボリック リンクを走査するパスを含む）は変更できない 必要があります。親ディレクトリとファイル システムのマウントは変更しないでください 実行ファイル内のパスの解決結果に影響を及ぼす 表示されます。

早期終了をキャッチするために、テストでは 開始時に TEST_PREMATURE_EXIT_FILE し、終了時に削除します。Bazel で検出されたコマンドが ファイルが予期せず終了した場合は、テストが早期に終了したと見なされ、 失敗としてマークします

タグの規則

テストルール内のタグの中には、特別な意味を持つものがあります。関連ドキュメント: tags 属性に関する Bazel ビルド エンサイクロペディア。

タグ 意味
exclusive 他のテストを同時に実行しない
external テストに外部依存関係がある場合。テスト キャッシュを無効にする
large test_suite 規則:一連の大規模なテストスイート
manual * ワイルドカードのターゲット パターンにテスト ターゲットを含めない :...、:*、または :all
medium test_suite 規則:中規模テストスイート
small test_suite 規則:小規模なテストスイートを使用して
smoke test_suite 規則:コンテナを実行する前に コードの変更をバージョン管理システムに commit する

実行ファイル

以下では、*_binary() ルールにラベルが付けられていると仮定します。 //foo/bar:unittest（ラベル付きのルールに対するランタイム依存関係あり） //deps/server:server。

場所

ターゲット //foo/bar:unittest の runfiles ディレクトリは、 $(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles。このパスは runfiles_dir。

依存関係

runfiles ディレクトリは、 *_binary() ルール。runfiles ディレクトリ自体が BUILD のセットに依存する *_binary() ルール、またはそのコンパイル時または実行時に影響するファイル 確認します。ソースファイルを変更しても、インフラストラクチャの構造には そのため、再ビルドはトリガーされません。

目次

runfiles ディレクトリには次のものが含まれます。

  • ランタイム依存関係へのシンボリック リンク: 各 OutputFile と CommandRule が *_binary() ルールのランタイム依存関係は、 runfiles ディレクトリのシンボリック リンクです。シンボリック リンクの名前は、 $(WORKSPACE)/package_name/rule_name。たとえば、server のシンボリック リンクが $(WORKSPACE)/deps/server/server という名前になり、フルパスは次のようになります。 $(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/server。 シンボリック リンクの宛先は OutputFile の OutputFileName() または CommandRule。絶対パスで表されます。したがって、コンテナの シンボリック リンクは $(WORKSPACE)/linux-dbg/deps/server/42/server の場合があります。
  • サブランファイルへのシンボリック リンク: ランタイムである *_binary() Z ごと *_binary() C の依存関係がある場合、実行ファイルに 2 つ目のリンクがあります。 C のディレクトリを Z の runfile にコピーします。シンボリック リンクの名前は、 $(WORKSPACE)/package_name/rule_name.runfiles。シンボリック リンクのターゲットは 自動的に作成します。たとえば、すべてのサブプログラムは共通のランファイルを共有します。 されます。