Реляционная базы данных — зверь сравнительно непознанный, и имеет репутацию генератора проблем. Не то, чтобы проблем не существовало, но как и с другими инструментами, чаще всего сложности возникают от неумения их (РСУБД) готовить.
Готовить с одной статьи не выучиться, но одно блюдо сдюжим.
Я постарался выделить скелет, набор скриптов, на базе которого можно делать свои схемы данных 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 — все созданные объекты и загруженные тестовые данные удаляются.
Ну вот наверное и всё пока.
Каюсь, вышло сумбурно — спрашивайте, что непонятно.
Пользуйтесь, разбирайтесь, форкайте!
Автор: CPro
