30.1. テストの実行

30.1.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

30.1.2. 既存のインストレーションに対するテストの実行

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

gmake installcheck

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

gmake installcheck-parallel

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

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

gmake installcheck

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

gmake installcheck

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

30.1.3. ホットスタンバイのテスト

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

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

30.1.4. ロケールと符号化方式

デフォルトでは、一時的なインストレーションに対するテストは、現在の環境で定義されたロケールとinitdbで決定される対応するデータベース符号化方式を使用します。 異なるロケールを試験する際は、以下の例のように適切な環境変数を設定することが有用です。

gmake check LANG=C
gmake check LC_COLLATE=en_US.utf8 LC_CTYPE=fr_CA.utf8

実装上の理由のため、LC_ALLはこの目的には動作しません。 この他のロケール関連の環境変数は動作します。

既存のインストレーションに対するテストでは、ロケールは既存のデータベースクラスタによって決まり、テスト実行時に別の値に設定することができません。

また、以下の例のようにENCODING変数を設定することで明示的にデータベース符号化方式を選択することができます。

gmake check LANG=C ENCODING=EUC_JP

この方法でデータベース符号化方式を設定することは、通常ロケールがCだった場合にのみ意味があります。 この他の場合、ロケールから自動的に符号化方式が選択されます。 ロケールと一致しない符号化方式を指定してもエラーになるだけです。

符号化方式は一時的なインストレーションに対するテストでも既存のインストレーションに対するテストでも設定することができます。

30.1.5. 追加のテスト

プラットフォームに依存する、または非常に時間がかかる可能性があるという理由で、リグレッションテスト一式にはデフォルトでは動作しないテストがいくつか含まれています。 EXTRA_TESTS変数を設定することでこれらの追加テストやその他のテストを実行することができます。 例えば、numeric_bigテストを以下のように実行します。

gmake check EXTRA_TESTS=numeric_big

以下のように照合順序テストを実行します。

gmake check EXTRA_TESTS=collate.linux.utf8 LANG=en_US.utf8

collate.linux.utf8テストは、Linux/glibcプラットフォームにおいてUTF-8符号化方式を使用するデータベースで実行した場合のみ動作します。