Реляционная базы данных — зверь сравнительно непознанный, и имеет репутацию генератора проблем. Не то, чтобы проблем не существовало, но как и с другими инструментами, чаще всего сложности возникают от неумения их (РСУБД) готовить.
Готовить с одной статьи не выучиться, но одно блюдо сдюжим.

Я постарался выделить скелет, набор скриптов, на базе которого можно делать свои схемы данных 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). Сразу предупреждаю — на Ubuntu 13 у них пакетов нет, они ориентируются на LTS релизы.

Скачиваем и устанавливаем последнюю версию pgTAP — фреймворка для тестирования всего и вся в PostgreSQL: pgtap.org

Архив распаковываем, дальше как обычно:

make && sudo make install

Теперь серверу postgres должно быть доступно расширение pgtap.

Устанавливаем pg_prove — perl утилиту для запуска тестов pgTAP

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# Как можно видеть по истории билдов и коммитам в гите — пришлось помучаться, чтобы развернуть на travis нужный postgres, установить расширение, 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 содержатся скрипты для создания схемы test_user (это просто пример схемы) с одной таблицей и несколькими примерами функций.

create_tables.sql — в каждой папке-схеме есть такой файл. В нём содержится DDL для создания объектов схемы.
create_functions.sql — скрипт, содержащий ф-ии схемы.
users_crud.sql — функций может быть много, поэтому они выделяются в разные файлы, которые подключаются в файле create_functions.sql командой \i (типа include).

Такое разбиение на отдельные файлы сэкономит нервы в будущем. Разделив в разных файлах создание таблиц, foreign constraints, ф-ии, отображения (views) и т.д., можно включать их в install.sql в правильной очерёдности, не попадая в ловушку взаимозависимостей типа таких:

  create table a (x int references b.y);
  create table b (y int references a.x);

Папка test тоже создаёт схему, но это особая схема, и живёт она только пока идут тесты.
setup.sql предназначен для загрузки ф-й и тестовых данных во временную схему test перед запуском тестов. (уф, сколько слова тест :)
run_tests.sh с помощью pg_prove по одному выполняет файлы ./tests/run_<имя>.sh
run_<имя>.sh создаются по одному на схему.
Сначала в них подключается файл setup.sql — который загружает определения тестовых функций, вспомогательную ф-ю test.test_scheme_check_func и тестовые данные из файла test_data.sh. Затем выполняются тесты, которые могут находиться в нескольких файлах, которые просто подключаются к run_<имя>.sh. После всех тестов в схеме, выполняется ф-я test.test_scheme_check_func. Эта ф-я сама является тестом pgTAP, который проваливается, если в схеме присутствуют не покрытые тестами ф-ии. Определение происходит по комментарию к тесту. Комментарий должен начинаться с названия тестируемой ф-ии. Конечно могут оказаться непокрытыми перегруженные ф-ии с одинаковыми названиями, но это лучше, чем никакого контроля покрытия тестами. После выполнения тестов происходит rollback — все созданные объекты и загруженные тестовые данные удаляются.

Ну вот наверное и всё пока.
Каюсь, вышло сумбурно — спрашивайте, что непонятно.
Пользуйтесь, разбирайтесь, форкайте!

Заготовка для схемы данных с тестами, CI, без преферанса