リレーショナルデータベースは比較的知られていない獣であり、問題を引き起こすという評判があります。 問題がなかったわけではありませんが、他のツールと同様に、ほとんどの場合、困難なのは調理できないこと（RDBMS）です。
1つの記事で料理することは学習しませんが、1つの料理は圧縮可能です。
独自のPostgreSQLデータスキームを作成し、pgTAPを使用してテストできるスケルトン、一連のスクリプトを選択しようとしました：
github.com/C-Pro/pg_skeletonそして、嬉しいボーナスとして、私はこのことをTravisにねじ込んだので、あなたもCIを始めに持っていました:)
インストールには、次のものが必要です。
- PostgreSQL> = 9.2とdevヘッダー（postgresの拡張機能をコンパイルする必要があります）
- pgTAP（拡張機能自体）
- テストを実行するpg_prove
だから、順番に：
PostgreSQLがまだインストールされていない場合-インストールします。 UbuntuまたはDebianを使用している場合は、apt.postgresql.orgリポジトリを接続することをお勧めします（接続手順については、wiki.postgresql.org / wiki / Aptを参照してください）。 すぐに警告します。Ubuntu13ではパッケージがなく、LTSリリースに焦点を当てています。
pgTAPの最新バージョンをダウンロードしてインストールします
-PostgreSQLのすべてをテストするためのフレームワーク：
pgtap.orgアーカイブを解凍してから、通常どおり：
make && sudo make install
これで、pgtap拡張機能がpostgresサーバーで使用可能になります。
pg_proveのインストール-pgTAPテストを実行するperlユーティリティ
sudo cpan TAP::Parser::SourceHandler::pgTAP
すべて、pg_skeletonをダウンロードしてインストールできます。
git clone https://github.com/C-Pro/pg_skeleton.git cd pg_skeleton cp install.cfg.example install.cfg ./install.sh
作成されたデータベースの所有者とpostgresユーザー-ユーザーに必要なパスワードを入力するように求められます。
次に、テストを実行します。
cd test ./run_tests.sh
PASSという魔法の言葉を見たなら、すべてが素晴らしいので、骨ごとにスケルトンを分解できます。 つまり、ファイルごとです。
- .gitignore-おそらく既に推測したとおり-gitによって無視されるファイルマスクのリスト
- .travis.yml-travisの構成ファイル。プロジェクトのインストール方法とテストの実行方法が記述されています。 このリポジトリにgit pushを行うと、travisはテストを実行し、何かが壊れていないかどうかを確認します。 travisビルドは次のようになります： travis-ci.org/C-Pro/pg_skeleton# gitのビルド履歴とコミットからわかるように、必要なpostgresをtravisにデプロイし、拡張機能をインストールし、pg_proveを実行してテストを実行するために苦労しました。
- create_db.sql-パラメーター化されたユーザー作成スクリプトとデータベース
- drop_db.sql-パラメーター化されたデータベースおよびユーザー削除スクリプト
- extensions.sql-スキームのインストール時に必要な拡張機能をインストールするスクリプト
- install.cfg-設定：postgresサーバーのアドレス、作成されたデータベースとユーザーの名前。 Gitは無視されるため、マシンと異なるサーバーにデプロイするときに、Gitで競合することなく異なる設定を使用できます。
- install.cfg.example-構成ファイルのテンプレート
- install.sql-データベースをインストールするSQLスクリプト。 データスキームを作成する他のすべてのSQLスクリプトが含まれています。
- uninstall.sh-データベースとユーザーを削除する実行可能スクリプト
各サブフォルダーは、含まれるスキーマに基づいて名前が付けられます。
test_userフォルダーには、1つのテーブルといくつかのサンプル関数を含むtest_userスキーマ（これは単なるスキーマの例です）を作成するためのスクリプトが含まれています。
- create_tables.sql-各スキームフォルダーにそのようなファイルがあります。 スキーマオブジェクトを作成するためのDDLが含まれています。
- create_functions.sql-スキーマ機能を含むスクリプト。
- users_crud.sql-多くの関数が存在する可能性があるため、\ iコマンド（includeタイプの）を使用してcreate_functions.sqlファイルで接続されているさまざまなファイルに割り当てられます。
この別々のファイルへの分割は、将来の神経を節約します。 テーブル、外部制約、関数、ビューなどの作成を異なるファイルに分けた後、これらの相互依存関係のtrapに陥ることなく、正しい順序でそれらをinstall.sqlに含めることができます。
create table a (x int references by); create table b (y int references ax);
テストフォルダーもスキーマを作成しますが、これは特別なスキーマであり、テストの実行中のみ有効です。
setup.sqlは、テストを実行する前にf番目とテストデータをテスト一時回路にロードするように設計されています。 （ええと、いくつの単語をテストします:)
run_tests.shはpg_proveを使用して、ファイル./tests/run_<name>.shを1つずつ実行します
run_ <name> .shはスキームごとに作成されます。
まず、setup.sqlファイルが接続されます。これにより、テスト関数、補助関数test.test_scheme_check_func、およびファイルtest_data.shからのテストデータの定義がロードされます。 次に、run_ <name> .shに接続するだけの複数のファイルに含まれる可能性のあるテストが実行されます。 回路内のすべてのテストの後、test.test_scheme_check_funcが実行されます。 このf-th自体はpgTAPテストであり、回路にカバーされていないf-tsが含まれていると失敗します。 決定は、テストのコメントに基づいています。 コメントは、テストf-sの名前で始まる必要があります。 もちろん、同じ名前のオーバーロードされた関数は明らかになる可能性がありますが、これはテストカバレッジを制御できないよりも優れています。 テストが完了すると、ロールバックが発生します。作成されたすべてのオブジェクトとロードされたテストデータが削除されます。
まあ、それはおそらく今のところすべてです。
私は告白しますが、混乱していることが判明しました-理解できないものを尋ねてください。
使用、理解、フォーク！