リグレッションテストは既にインストールされ稼働中のサーバや、ビルドツリー内の一時的なインストレーションに対して実行することができます。 さらに、テストの実行には「並行」と「連続」モードがあります。 連続モードでは個々のテストスクリプトを単独で実行し、並行モードでは複数のサーバプロセスを実行し、テストをグループ化して並行的に実行します。 並行テストではプロセス間通信とロック機能が正常に作動しているかをテストします。
構築後、インストール前に並行リグレッションテストを行う場合には、最上位のディレクトリで以下のように入力してください。
make check
(または、src/test/regress
ディレクトリに移動して、そこで実行してください。)
終了したら以下のような表示がされるはずです。
=======================
All 193 tests passed.
=======================
これが表示されなければ、テストは失敗したことになります。 「失敗」を深刻な問題であると推測する前に、以下の 32.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
インストール(第16章を参照)後にテストを実行するには、第18章で説明したようにデータディレクトリを初期化し、サーバを起動し、そして以下を入力してください。
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
モジュールにテストがあるわけではありません。
ECPGインタフェースライブラリのリグレッションテスト。
src/interfaces/ecpg/test
にあります。
コアがサポートする認証方式のテスト。
src/test/authentication
にあります。
(認証に関連する追加のテストについては下記を参照してください。)
同時実行中のセッションの振舞いの負荷テスト。
src/test/isolation
にあります。
クラッシュリカバリと物理レプリケーションのテスト。
src/test/recovery
にあります。
論理レプリケーションのテスト。
src/test/subscription
にあります。
src/bin
以下のクライアントプログラムのテスト。
32.4も参照してください。
installcheck
モードを使う場合には、上記のテストは名前regression
を含むテストデータベースを破壊します。例えば、pl_regression
、contrib_regression
です。
非テストデータベースがそのように名付けられたインストレーションでinstallcheck
モードを使う場合には注意してください。
この補助的なテストスイートの中には32.4で説明するTAP基盤を使うものがあります。
オプション--enable-tap-tests
を指定してPostgreSQLを構築した場合にのみ、TAPベースのテストが行なわれます。
これは開発にはお薦めですが、適切なPerlのインストレーションがない場合には省略できます。
マルチユーザシステムにおいて安全に実行できない、あるいは、特別なソフトウェアを必要とする、といういずれかの理由により、一部のテストスイートはデフォルトでは実行されません。
どのテストスイートを追加で実行するかをmake
や環境変数PG_TEST_EXTRA
に空白区切りのリストを設定することで決定できます。
以下に例を示します。
make check-world PG_TEST_EXTRA='kerberos ldap ssl'
現在、以下の値がサポートされます。
kerberos
src/test/kerberos
以下のテストスイートを実行します。
これはMIT Kerberosのインストールを必要とし、TCP/IPリッスンソケットを開きます。
ldap
src/test/ldap
以下のテストスイートを実行します。
これはOpenLDAPのインストールを必要としTCP/IPリッスンソケットを開きます。
ssl
src/test/ssl
以下のテストスイートを実行します。
これはTCP/IPリッスンソケットを開きます。
現在のビルド設定ではサポートされない機能のテストは、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だった場合にのみ意味があります。 この他の場合、ロケールから自動的に符号化方式が選択されます。 ロケールと一致しない符号化方式を指定してもエラーになるだけです。
データベース符号化方式は一時的なインストレーションに対するテストでも既存のインストレーションに対するテストでも設定することができます。 ただし、後者の場合にはインストレーションのロケールと互換性がなければなりません。
プラットフォームに依存する、または非常に時間がかかる可能性があるという理由で、コアリグレッションテスト一式にはデフォルトでは動作しないテストがいくつか含まれています。
EXTRA_TESTS
変数を設定することでこれらの追加テストやその他のテストを実行することができます。
例えば、numeric_big
テストを以下のように実行します。
make check EXTRA_TESTS=numeric_big
以下のように照合順序テストを実行します。
make check EXTRA_TESTS='collate.linux.utf8 collate.icu.utf8' LANG=en_US.utf8
collate.linux.utf8
テストは、Linux/glibcプラットフォームにおいてのみ動作します。
collate.icu.utf8
テストは、ICUをサポートするよう構築した場合にのみ動作します。
どちらのテストも、UTF-8符号化方式を使用するデータベースで実行した場合にのみ成功するでしょう。
ソース配布は、ホットスタンバイの静的な挙動に対するリグレッションテストも含んでいます。 これらのテストは、稼働しているプライマリサーバと、(ファイルベースのログ転送、またはストリーミングレプリケーションによって)プライマリからの新規のWALの変更を受け付けられる稼働中のスタンバイサーバを必要とします。 これらのサーバは、自動的に作成されませんし、ここにはレプリケーション設定ドキュメントもありません。 必要なコマンドや関連する問題について記述されている、ドキュメントのさまざまなセクションを参照してください。
ホットスタンバイテストを実行するには、最初に"regression"という名前のデータベースをプライマリに作成します。
psql -h primary -c "CREATE DATABASE regression"
次に、準備のためのスクリプトsrc/test/regress/sql/hs_primary_setup.sql
をプライマリのregressionデータベース上で以下のように実行します。
psql -h primary -f src/test/regress/sql/hs_primary_setup.sql regression
この変更がスタンバイに伝搬するようにします。
ここで、デフォルトデータベース接続がスタンバイサーバの試験環境になるように(例えば、PGHOST
とPGPORT
環境変数を設定することで)手配してください。
最後に、リグレッションテスト用のディレクトリからmake standbycheck
を実行してください。
cd src/test/regress make standbycheck
いくつかの極端な挙動を、スタンバイのテストのための挙動を実現するスクリプトsrc/test/regress/sql/hs_primary_extremes.sql
を用いることでプライマリサーバ上で生成することができます。