Тестирование хранимых функций с помощью pgTAP

в 1:21, , рубрики: pgTAP, postgresql, unit-testing, Unit-тестирование, Администрирование баз данных, тестирование, метки: , , ,

Недавно я выложил статью со «скелетом» схемы данных, который можно использовать для создания своих схем PostgreSQL.
Помимо собственно скриптов разворачивания схемы, создания объектов, там были примеры хранимых функций и Unit-тесты на них.

Тестирование хранимых функций с помощью pgTAP

В этой статье я хочу на примере pg_skeleton подробней остановиться на том, как писать тесты для хранимых функций PostgreSQL при помощи pgTAP.

Тесты pgTAP, как следует из названия, на выходе выдают текст в простом текстовом формате TAP (Test Anything Protocol). Этот формат принимается многими CI системами. Мы используем Jenkins TAP Plugin.

При установке расширения, в базе создаются хранимые функции (по-умолчанию в схеме public), которые мы будем использовать при написании тестов. Большая часть функций — различные assert'ы. С полным списком можно ознакомиться здесь: http://pgtap.org/documentation.html

Тестировать будем функции из примера схемы test_user:
Сначала устанавливаем pg_skeleton. (Если хотите сразу писать тесты в своей схеме — из инструкции по установке pg_skeleton выполните лишь часть про pgtap и загрузите расширение в бд)

Тесты я постарался сделать похожими на те, что используются в реальных проектах, и использовать побольше разных ф-ий pgTAP.
Перед началом выполнения тестов необходимо указать их количество, вызвав функцию plan(int).
В нашем примере этот вызов находится в файле test/tests/run_user.sql:

select plan(7+2+1);

В данном случае, 7 — это количество тестов запускаемых из файла user_crud.sql (тесты ф-ий), 2 — количество тестов в файле user_schema.sql, 1 — однострочный тест (проверяющий покрытие функций тестами) непосредственно в файле run_user.sql.
В документации pgTAP рассматриваются в-основном тесты вызываемые отдельными select запросами — это подходит для тестирования схемы, или проверки простых ф-ий, не имеющих побочных эффектов (такие тесты в user_schema.sql).
Но при тестировании сложных сценариев, когда необходимо вызывать несколько ф-ий, и в следующую передаётся результат предыдущей, можно объединять тесты в хранимую функцию, которая будет выполнять сценарий, содержащий несколько тестов. Пример такой функции в файле test/functions_user.sql.
Функцию нужно объявлять, как возвращающую множество строк:

create or replace function test.test_user_0010()
returns setof text as $$
--Номер в названии ф-ии необязателен, но может быть полезен для запуска тестовых ф-ий
--в определённом порядке при запуске тестов при помощи runtests().

--Объявим переменную, в которой будем хранить идентификатор добавленной записи:
declare
 v_user_id integer;
begin
  --Первый тест - проверяем, что функция добавления отрабатывает, не вызывая исключений:
  return next lives_ok('select test_user.add_user(''testuser unique''::varchar);',
                       'test_user.add_user doesnt throw exception');
  --Добавляем ещё одну запись, сохраняем её идентификатор, проверяем, что он корректен (>0):
  v_user_id := test_user.add_user('blah blah');
  return next cmp_ok(v_user_id,
                     '>',
                     0,
                     'test_user.add_user: returns ok');
  --Проверим, что запись действительно есть.
  return next results_eq('select user_name::varchar from test_user.users where user_id=' || v_user_id::varchar,
                         'select ''blah blah''::varchar',
                         'test_user.add_user inserts ok');
  --Функция изменения пользователя должна возвращать идентификатор пользователя:
  return next is(test_user.alter_user(v_user_id,'new user name blah'),
                 v_user_id,
                 'test_user.alter_user: returns ok');
  --Проверим, что запись действительно изменилась:
  return next results_eq('select user_name::varchar from test_user.users where user_id=' || v_user_id::varchar,
                         'select ''new user name blah''::varchar',
                         'test_user.alter_user updates record');
  --Функция удаления пользователя должна возвращать его id:
  return next is(test_user.delete_user(v_user_id),
                 v_user_id,
                 'test_user.delete_user: returns ok');
 --Последний тест. Проверим, что пользователь действительно удалён:
  return next is_empty('select 1 from test_user.users where user_id=' || v_user_id::varchar,
                       'test_user.delete_user: deletes ok');
end;
$$ language plpgsql;

Запускать тесты можно непосредственно из sql:

psql -h $db_host -p $db_port -U $db_user $db_name -f tests/run_user.sql

в этом случае мы получим чистый TAP на выходе:

plan|1..10
test_user_0010|ok 1 - test_user.add_user doesnt throw exception
test_user_0010|ok 2 - test_user.add_user: returns ok
test_user_0010|ok 3 - test_user.add_user inserts record
test_user_0010|ok 4 - test_user.alter_user: returns ok
test_user_0010|ok 5 - test_user.alter_user updates record
test_user_0010|ok 6 - test_user.delete_user: returns ok
test_user_0010|ok 7 - test_user.delete_user: deletes ok
tables_are|ok 8 - Schema test_user contains users table
columns_are|ok 9 - test_user.users column check
test_scheme_check_func|ok 10 - All functions in schema test_user are covered with tests.

Либо при помощи утилиты pg_prove:

pg_prove -h $db_host -p $db_port -d $db_name -U $db_user tests/run_*.sql

Тогда вывод будет более чиловекочитаемый:

tests/run_user.sql .. ok     
All tests successful.
Files=1, Tests=10,  0 wallclock secs ( 0.04 usr +  0.00 sys =  0.04 CPU)
Result: PASS

В pg_skeleton переменные для хоста, порта, имени пользователя и бд за вас подставит скрипт /test/run_tests.sh

Надеюсь, что теперь у всех, у кого есть код в хранимых функциях PostgreSQL, будут unit-тесты!

Автор: CPro

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js