Pull to refresh

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

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

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

Ну вот наверное и всё пока.
Каюсь, вышло сумбурно — спрашивайте, что непонятно.
Пользуйтесь, разбирайтесь, форкайте!
Tags:
Hubs:
Total votes 9: ↑7 and ↓2 +5
Views 8.9K
Comments Leave a comment