30.1. テストの実行

リグレッションテストは既にインストールされ稼働中のサーバや、ビルドツリー内の一時的なインストレーションに対して実行することができます。 さらに、テストの実行には、"並行"と"連続"モードがあります。 連続モードでは個々のテストスクリプトを単独で実行し、並行モードでは複数のサーバプロセスを実行し、テストをグループ化して並行的に実行します。 並行テストではプロセス間通信とロック機能が正常に作動しているかをテストします。

構築後、インストール前に並行リグレッションテストを行う場合には、最上位のディレクトリで以下のように入力してください。

gmake check

（または、src/test/regressディレクトリに移動して、そこで実行してください。） 実行すると、ユーザ定義のトリガ関数のサンプルなど、複数の補助的なファイルがまず作成され、それからテストドライバのスクリプトを実行します。 終了したら、以下のような表示がされるはずです。

=======================
 All 115 tests passed.
=======================

これが表示されなければ、テストは失敗したことになります。 "失敗"を深刻な問題であると推測する前に、以下の 項30.2 を参照してください。

この試験方法では、一時的にサーバを起動させるため、rootユーザでは動作しません （サーバはrootでは起動しません）。 rootで構築作業を行ったとしても、全てを最初からやり直す必要はありません。 リグレッションテストのディレクトリを他のユーザから書き込み可能にし、そのユーザでログインしてテストを再実行してください。 例えば、以下のようにします。

root# chmod -R a+w src/test/regress
root# su - joeuser
joeuser$ cd top-level build directory
joeuser$ gmake check

（この方法には"セキュリティリスク"が1つだけあります。 それは、別のユーザがこっそりリグレッションテストの結果を変更することが可能ということです。 ユーザ権限の付与には常識を働かせてください。）

あるいは、インストール後にテストを実行することも可能です。

古いPostgreSQLのインストレーションが既に存在している場所にPostgreSQLをインストールするように構築した場合、新しいバージョンをインストールする前にgmake checkを行うと、新しいプログラムがインストール済みの共有ライブラリを使用しようとするために試験が失敗することになります （典型的な症状は、未定義シンボルに関するエラーメッセージです）。 古いインストレーションを上書きする前に試験を行いたいのであれば、configure --disable-rpathで構築する必要があります。 しかし、このオプションを最終的なインストレーションで使用することは推奨しません。

並行リグレッションテストは、実行したユーザのユーザIDを使用して相当数のプロセスを起動します。 現在、最大で20個の並行テストスクリプトが同時に実行されますが、これは合計40個のプロセスが実行されることを意味します: 各テストスクリプトに対して、1つのサーバプロセスと1つのpsqlプロセスが存在するためです。 ですので、使用するシステムでユーザ当たりのプロセス数に制限を加えている場合は、その上限が少なくとも50程度であることを確認してください。 さもないと、並行テストにおいて、ランダムに発生しているように見える失敗が発生するかもしれません。 この上限を変更できない場合は、MAX_CONNECTIONSパラメータを編集して、並行度を減らすことができます。 例えば、以下は同時実行数を10以下で実行します。

gmake MAX_CONNECTIONS=10 check

runs no more than ten tests concurrently.

インストール（第15章を参照）後にテストを実行するには、第17章で説明したようにデータ領域を初期化し、サーバを起動させ、そして以下を入力してください。

gmake installcheck

もしくは、並行テストの場合は以下を入力してください。

gmake installcheck-parallel

テストは、PGHOST環境変数とPGPORT環境変数で指定がない限り、ローカルホストのサーバに接続し、デフォルトのポート番号を使用します。

ソース配布には、オプションとなっている手続き言語と一部のcontribモジュールに対するリグレッションテストも含まれています。 現在、これらのテストはインストール済みのサーバに対してのみ使用することができます。 構築されインストールされたすべての手続き言語に対してテストを実行するには、構築ツリーのsrc/plディレクトリに移動し、以下を実行してください。

gmake installcheck

また、これをsrc/plのいずれかのサブディレクトリで実行して、1つの手続き言語のみに対するテストを行うこともできます。 テストが提供されているすべてのcontribモジュールに対するテストを実行するには、構築ツリーのcontribディレクトリに移動し、以下を実行してください。

gmake installcheck

事前にcontribモジュールが構築されインストールされていなければなりません。 また、これをcontribのサブディレクトリで実行して、1つのモジュールのみに対してテストを行うことができます。

ソース配布は、ホットスタンバイの静的な挙動に対するリグレッションテストも含んでいます。 これらのテストは、稼働しているプライマリサーバと、ファイルベースのログ転送、またはストリーミングレプリケーションによって新規の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

ここで、試験用のデフォルト接続がスタンバイサーバの試験環境であることを確認してください。 そしてリグレッションテスト用のディレクトリから standbycheck ターゲットを実行してください。

cd src/test/regress
gmake standbycheck

いくつかの極端な挙動を、スクリプトを用いることでプライマリサーバ上で生成することができます： src/test/regress/sql/hs_primary_extremes.sql によって、スタンバイのテストのための挙動を実現できます。

今後のリリースでさらに自動化された試験ができるようになるかもしれません。