Posted inデータベース

PostgreSQLにおけるpgTAPを用いたデータベーステスト：関数、トリガー、スキーマのユニットテストガイド

Database tutorial - IT technology blog
Database tutorial - IT technology blog

なぜデータベーステストは軽視されがちなのか

キャリアの初期、アプリケーションコードとは無関係な本番環境のバグ修正で、多くの夜を明かしたことがあります。原因の多くは、誰かがPostgreSQLの関数を更新した際に、他の場所にあるトリガーが壊れたことに気づかなかったことでした。

これまで様々なプロジェクトでMySQL、PostgreSQL、MongoDBを扱ってきましたが、それぞれに強みがあります。中でもPostgreSQLは、PL/pgSQLを介してデータベース内で複雑なロジックを直接処理できる能力が際立っています。しかし、大きな力にはテストという責任が伴います。

多くの開発者は、Python、Java、Node.jsのコードのユニットテストには注力しますが、データベースはブラックボックスとして扱いがちです。「マイグレーションが実行できれば、データベースは問題ない」と思い込んでしまうのです。この考え方は、システムを脆弱にします。pgTAPは、Test Anything Protocol (TAP) をPostgreSQLに直接導入することで、純粋なSQLでテストを書くことを可能にし、この状況を変えてくれます。

データベーステスト手法の比較

データベースのロジックを検証する場合、主に3つのアプローチがあります。ロジックがどこに存在するかによって、それぞれ適したユースケースがあります。

1. アプリケーションレベルのテスト（標準的な方法）

これは、PytestやJUnitなどのフレームワークを使用してデータベースとやり取りする方法です。データを挿入し、関数を呼び出し、データベースの状態をアサートします。統合テストとしては有効ですが、すべてのテストにネットワークのラウンドトリップが必要なため低速です。また、データベース内部の制約やトリガーを単体でテストするのは困難です。

2. 手動検証（リスクの高い方法）

多くのジュニア開発者は、変更を加えた後に SELECT * FROM table を手動で実行します。クイックチェックには適していますが、スケールさせるのは不可能です。人間の記憶に頼ることになり、デグレード（先祖返り）の主な原因となります。

3. pgTAPによるデータベースネイティブなテスト（プロの方法）

pgTAPを使用すると、テストをSQLスクリプトとして記述できます。これらのテストはデータベースエンジン内で実行されます。pgTAPはトランザクションを使用するため、各テストは変更を自動的にロールバックし、データベースをクリーンな状態に保ちます。アプリケーションレベルのテストよりも大幅に高速で、スキーマ、関数、権限のきめ細かな検証が可能です。

pgTAPを使用するメリットとデメリット

pgTAPをワークフローに統合する前に、その長所と短所を理解しておくことが重要です。

メリット

  • スピード: テストはエンジン内でローカルに実行されるため、ネットワーク遅延がありません。
  • 隔離性: テストはトランザクションにラップされます。テストデータのクリーニングを心配する必要はありません。
  • 包括的: テーブル構造やカラム型から、複雑なトリガーロジックやユーザー権限まで、あらゆるものをテストできます。
  • CI/CDとの親和性: Jenkins、GitHub Actions、GitLab CIなどで簡単に読み取れるTAP準拠の結果を出力します。

デメリット

  • 学習曲線: pgTAPが提供する特定のSQL関数セットを学ぶ必要があります。
  • 環境構築: PostgreSQLサーバーに拡張機能をインストールする必要があります。一部のマネージドクラウド環境では制限がある場合があります（ただし、AWS RDSなどはサポートしています）。

推奨されるセットアップ

開始するには、データベース内の pgtap 拡張機能と、テストを実行するための pg_prove コマンドラインツール（Perlの TAP::Parser::SourceHandler::pgTAP モジュールの一部）の2つが必要です。

拡張機能のインストール

Debian/Ubuntuシステムでは、パッケージマネージャーを使用して拡張機能をインストールできます。

sudo apt-get install postgresql-15-pgtap

次に、データベースで有効にします。

CREATE EXTENSION pgtap;

pg_proveのインストール

テストを実行する最も簡単な方法は pg_prove を使うことです。CPANまたはパッケージマネージャーを使用してインストールしてください。

sudo cpan TAP::Parser::SourceHandler::pgTAP

あるいは、Dockerを好む場合は、多くのPostgreSQLイメージにpgTAPがプリインストールされています。また、ローカル環境を汚さないために専用のテストコンテナを使用することもできます。

実装ガイド：最初のテストを書く

具体的なシナリオを見ていきましょう。users テーブルと、割引を計算する関数を持つシンプルなEコマースのスキーマがあると仮定します。

1. スキーマのテスト

まず、テーブルとカラムが正しいデータ型で存在することを確認します。これにより、マイグレーション中の誤った削除や型の変更を防ぐことができます。

-- テストファイルを作成: test_schema.sql
BEGIN;
SELECT plan(3); -- 3つのテストを実行予定

-- テーブルが存在するか確認
SELECT has_table('users');

-- 特定のカラムが存在するか確認
SELECT has_column('users', 'email');

-- カラムのデータ型を確認
SELECT col_type_is('users', 'email', 'character varying(255)');

SELECT * FROM finish();
ROLLBACK;

2. 関数のテスト

関数内部のロジックのテストこそ、pgTAPが真価を発揮する場面です。10%の割引を返す calculate_discount(price numeric) 関数を想定してみましょう。

-- テストファイルを作成: test_functions.sql
BEGIN;
SELECT plan(2);

-- 標準的な割引をテスト
SELECT is(
    calculate_discount(100.00),
    90.00,
    'calculate_discountは基本価格100に対して90を返すべきです'
);

-- 価格が0の場合をテスト
SELECT is(
    calculate_discount(0),
    0.00,
    'calculate_discountは入力が0の場合を処理すべきです'
);

SELECT * FROM finish();
ROLLBACK;

3. トリガーのテスト

トリガーはデバッグが難しいことで有名です。pgTAPを使用すると、ユーザーのメールアドレスが変更されたときに、トリガーが監査ログ（audit log）を正しく更新するかどうかをテストできます。

-- テストファイルを作成: test_triggers.sql
BEGIN;
SELECT plan(1);

-- ダミーユーザーを挿入
INSERT INTO users (id, email) VALUES (1, '[email protected]');

-- トリガーを発動させるために更新を実行
UPDATE users SET email = '[email protected]' WHERE id = 1;

-- audit_logテーブルに変更が記録されたか確認
SELECT results_eq(
    'SELECT old_email FROM audit_log WHERE user_id = 1',
    $$VALUES ('[email protected]')$$,
    'トリガーはaudit_logに古いメールアドレスを記録すべきです'
);

SELECT * FROM finish();
ROLLBACK;

テストの実行

SQLテストファイルの準備ができたら、 pg_prove を使用して実行します。このツールは、成功したテストと失敗したテストの分かりやすい要約を表示します。

pg_prove -d my_database_name test_schema.sql test_functions.sql test_triggers.sql

出力は以下のようになります。

test_schema.sql .... ok
test_functions.sql . ok
test_triggers.sql .. ok
All tests successful.
Files=3, Tests=6,  1 wallclock secs

データベースユニットテストのベストプラクティス

プロジェクトの成長に合わせてテストスイートのメンテナンス性を維持するために、以下のガイドラインに従ってください。

  • トランザクションを使用する: テストコードは常に BEGIN; と ROLLBACK; で囲んでください。これにより、テストデータが残らず、データベースを既知の状態に保つことができます。
  • モジュールごとに整理する: システムの各部分（例：auth_tests.sql、billing_tests.sql）ごとに個別の .sql ファイルを作成します。
  • CIで自動化する: プルリクエストのパイプラインの一部として pg_prove を実行します。マイグレーションによって関数が壊れた場合、コードがステージング環境に到達する前にCIが失敗するようにします。
  • テストしすぎない: 複雑なロジック（関数、トリガー、制約）に集中してください。id が主キーであることをテストするのは有用ですが、小規模なプロジェクトですべての些細なカラムをテストするのは過剰かもしれません。

データベースロジックを第一級のコードとして扱い、pgTAPによるユニットテストの原則を適用することで、データの破損やロジックエラーのリスクを大幅に軽減できます。事前の準備に多少の時間はかかりますが、金曜午後のデプロイ時に得られる安心感は、その時間に見合う価値があります。

Share:
Tags: