リグレッションテストは既にインストールされ稼働中のサーバや、ビルドツリー内の一時的なインストレーションに対して実行することができます。 さらに、テストの実行には「並行」と「連続」モードがあります。 連続モードでは個々のテストスクリプトを単独で実行し、並行モードでは複数のサーバプロセスを実行し、テストをグループ化して並行的に実行します。 並行テストではプロセス間通信とロック機能が正常に作動しているかをテストします。 テストの中には、テストによって要求されている場合には「並行」モードであっても連続的に実行するものがあるかもしれません。
構築後、インストール前に並行リグレッションテストを行う場合には、最上位のディレクトリで以下のように入力してください。
make check
(または、src/test/regress
ディレクトリに移動して、そこで実行してください。)
並行的に実行されるテストは前に「+」が付いていて、連続的に実行されるテストは前に「-」が付いています。
終了したら以下のような表示がされるはずです。
# All 213 tests passed.
これが表示されなければ、テストは失敗したことになります。 「失敗」を深刻な問題であると推測する前に、以下の 33.2 を参照してください。
この試験方法では、一時的にサーバを起動するので、rootユーザとして構築を行なった場合には動作しません。 サーバがrootでは起動しないからです。 rootで構築をしないこと、もしくはインストール完了後に試験を実施することをお薦めします。
古いPostgreSQLのインストレーションが既に存在している場所にPostgreSQLをインストールするように構築した場合、新しいバージョンをインストールする前にmake check
を行うと、新しいプログラムがインストール済みの共有ライブラリを使用しようとするために試験が失敗することになります。
(典型的な症状は、未定義シンボルに関するエラーメッセージです。)
古いインストレーションを上書きする前に試験を行いたいのであれば、configure --disable-rpath
で構築する必要があります。
しかし、このオプションを最終的なインストレーションで使用することは推奨しません。
並行リグレッションテストは、実行したユーザのユーザIDを使用して相当数のプロセスを起動します。
現在、最大で20個の並行テストスクリプトが同時に実行されますが、これは合計40個のプロセスが実行されることを意味します。
各テストスクリプトに対して、1つのサーバプロセスと1つのpsqlプロセスが存在するためです。
ですので、使用するシステムでユーザ当たりのプロセス数に制限を加えている場合は、その上限が少なくとも50程度であることを確認してください。
さもないと、並行テストにおいて、ランダムに発生しているように見える失敗が発生するかもしれません。
この上限を変更できない場合は、MAX_CONNECTIONS
パラメータを編集して、並行度を減らすことができます。
例えば、以下は同時実行数を10以下で実行します。
make MAX_CONNECTIONS=10 check
インストール(第17章を参照)後にテストを実行するには、第19章で説明したようにデータディレクトリを初期化し、サーバを起動し、そして以下を入力してください。
make installcheck
もしくは、並行テストの場合は以下を入力してください。
make installcheck-parallel
テストでは、PGHOST
環境変数とPGPORT
環境変数で指定がない限り、ローカルホストのサーバに接続し、デフォルトのポート番号を使用します。
テストはregression
という名前のデータベースで行なわれます。
この名前の既存のデータベースはすべて削除されます。
テストは、ロールやテーブル空間、サブスクリプションのようなクラスタ全体にわたるオブジェクトも一時的に作成します。
このオブジェクトの名前はregress_
で始まります。
実際のグローバルオブジェクトがそのように名付けられたインストレーションでinstallcheck
モードを使う場合には注意してください。
make check
とmake installcheck
コマンドは「コア」リグレッションテストだけを実行します。
そのテストはPostgreSQLサーバに組み込まれている機能のみをテストします。
ソース配布には、オプションとなっている手続き言語のような追加機能とその多くが関係のある追加のテストスイートが多く含まれています。
コアテストを含む、構築するよう選択されたモジュールに適用できるテストスイートをすべて実行するにはビルドツリーの最上位で以下のコマンドの一つを入力して下さい。
make check-world make installcheck-world
make check
とmake installcheck
で以前述べたように、このコマンドは、それぞれ、一時的なサーバもしくは既にインストールされているサーバを使ってテストを行ないます。
それ以外に考慮すべきことはそれぞれのところで以前述べたことと同じです。
make check-world
はテストするモジュール毎に別のインスタンス(一時的なデータディレクトリ)を構築しますので、make installcheck-world
よりもずっとより多くの時間とディスク容量が必要です。
複数のCPUコアがあり、オペレーティングシステムの厳しい制限のない最近のマシンでは、並列処理でかなり速くできます。 ほとんどのPostgreSQL開発者がテストをすべて実行するのに実際に使っている方法は以下のようなものです。
make check-world -j8 >/dev/null
ここで-j
の範囲は利用可能なコアの数に近い、もしくはそれより少し多い値です。
stdoutを捨てることで、成功を検証する時には興味のない出力を除きます。(失敗した場合、どこをより詳細に調べるべきか決めるにはstderrメッセージでたいてい十分です。)
代わりに、構築ツリーの適切なサブディレクトリでmake check
またはmake installcheck
と入力することで個々のテストスイートを実行することもできます。
make installcheck
はコアサーバだけでなく、関係のあるモジュールもインストール済みであると仮定することを覚えておいて下さい。
このように実行できる追加のテストには以下のものが含まれます。
オプションとなっている手続き言語のリグレッションテスト。
これはsrc/pl
にあります。
contrib
の下にあるcontrib
モジュールのリグレッションテスト。
すべてのcontrib
モジュールにテストがあるわけではありません。
src/interfaces/libpq/test
とsrc/interfaces/ecpg/test
にあるインタフェースライブラリのリグレッションテスト。
コアがサポートする認証方式のテスト。
src/test/authentication
にあります。
(認証に関連する追加のテストについては下記を参照してください。)
同時実行中のセッションの振舞いの負荷テスト。
src/test/isolation
にあります。
クラッシュリカバリと物理レプリケーションのテスト。
src/test/recovery
にあります。
論理レプリケーションのテスト。
src/test/subscription
にあります。
src/bin
以下のクライアントプログラムのテスト。
installcheck
モードを使う場合には、上記のテストは名前regression
を含むテストデータベースを破壊します。例えば、pl_regression
、contrib_regression
です。
非テストデータベースがそのように名付けられたインストレーションでinstallcheck
モードを使う場合には注意してください。
この補助的なテストスイートの中には33.4で説明するTAP基盤を使うものがあります。
オプション--enable-tap-tests
を指定してPostgreSQLを構築した場合にのみ、TAPベースのテストが行なわれます。
これは開発にはお薦めですが、適切なPerlのインストレーションがない場合には省略できます。
マルチユーザシステムにおいて安全に実行できない、特別なソフトウェアを必要とする、あるいは、リソースを大量に使うといういずれかの理由により、一部のテストスイートはデフォルトでは実行されません。
どのテストスイートを追加で実行するかをmake
や環境変数PG_TEST_EXTRA
に空白区切りのリストを設定することで決定できます。
以下に例を示します。
make check-world PG_TEST_EXTRA='kerberos ldap ssl load_balance'
現在、以下の値がサポートされます。
kerberos
src/test/kerberos
以下のテストスイートを実行します。
これはMIT Kerberosのインストールを必要とし、TCP/IPリッスンソケットを開きます。
ldap
src/test/ldap
以下のテストスイートを実行します。
これはOpenLDAPのインストールを必要としTCP/IPリッスンソケットを開きます。
ssl
src/test/ssl
以下のテストスイートを実行します。
これはTCP/IPリッスンソケットを開きます。
load_balance
src/interfaces/libpq/t/004_load_balance_dns.pl
テストを実行します。
これには、システムのhosts
ファイルを編集することが必要で、TCP/IPリッスンソケットを開きます。
wal_consistency_checking
src/test/recovery
で特定のテストを実行する際にwal_consistency_checking=all
を使用します。
リソースを大量に消費するため、デフォルトでは有効になっていません。
現在のビルド設定ではサポートされない機能のテストは、PG_TEST_EXTRA
に記述されていても、実行されません。
さらに、make check-world
では実行されますが、make installcheck-world
では実行されないテストがsrc/test/modules
にあります。
これは、実運用向けではない拡張をインストールしたり、実運用のインストレーションには望ましくない副作用があったりするためです。
お望みとあらば、そのサブディレクトリの1つでmake install
とmake installcheck
を使うことはできますが、テスト用でないサーバでそうすることはお勧めしません。
デフォルトでは、一時的なインストレーションを使うテストは、現在の環境で定義されたロケールとinitdb
で決定される対応するデータベース符号化方式を使用します。
異なるロケールを試験する際は、以下の例のように適切な環境変数を設定することが有用です。
make check LANG=C make check LC_COLLATE=en_US.utf8 LC_CTYPE=fr_CA.utf8
実装上の理由のため、LC_ALL
はこの目的には動作しません。
この他のロケール関連の環境変数は動作します。
既存のインストレーションに対するテストでは、ロケールは既存のデータベースクラスタによって決まり、テスト実行時に別の値に設定することができません。
また、以下の例のようにENCODING
変数を設定することで明示的にデータベース符号化方式を選択することができます。
make check LANG=C ENCODING=EUC_JP
この方法でデータベース符号化方式を設定することは、通常ロケールがCだった場合にのみ意味があります。 この他の場合、ロケールから自動的に符号化方式が選択されます。 ロケールと一致しない符号化方式を指定してもエラーになるだけです。
データベース符号化方式は一時的なインストレーションに対するテストでも既存のインストレーションに対するテストでも設定することができます。 ただし、後者の場合にはインストレーションのロケールと互換性がなければなりません。
リグレッションテストスイートを実行する際に使用するカスタムサーバ設定は、(以下を有効にするためには)PGOPTIONS
環境変数で設定できます。
make check PGOPTIONS="-c debug_parallel_query=regress -c work_mem=50MB"
一時的なインストールに対して実行する際には、前もって書き込んでおいたpostgresql.conf
を用意することによってもカスタム設定に反映できます。
echo 'log_checkpoints = on' > test_postgresql.conf echo 'work_mem = 50MB' >> test_postgresql.conf make check EXTRA_REGRESS_OPTS="--temp-config=test_postgresql.conf"
これは追加のログ取得、リソース制限の調整、debug_discard_cachesのような追加の実行時チェックを可能にするために有効かもしれません。
プラットフォームに依存する、または非常に時間がかかる可能性があるという理由で、コアリグレッションテスト一式にはデフォルトでは動作しないテストがいくつか含まれています。
EXTRA_TESTS
変数を設定することでこれらの追加テストやその他のテストを実行することができます。
例えば、numeric_big
テストを以下のように実行します。
make check EXTRA_TESTS=numeric_big