Юнит-тестирование на уровне базы данных PostgreSQL

• Обнаруживать ошибки на ранних этапах. Можно выявлять ошибки до публикации на продуктовые сервера и влияния на другие функции.
  
• Предотвратить регрессию.Юнит-тесты значительно облегчают процесс рефакторинга и изменение кода, т. к. легко убедиться в корректности изменений и в том, что изменения не сломали уже работающую функциональность. Это особенно важно в больших командах и при наличии зависимостей между функциями.
  
• Оптимизировать производительность. Юнит-тесты позволяют вовремя выявлять деградацию производительности, например, при увеличении объема данных либо при изменении связанной функции.
  
• Поддержать CI/CD. Можно реализовать быструю автоматическую проверку качества кода перед его деплоем. 
  
• Повышать доверие к системе со стороны пользователей. Можно улучшить общую стабильность и надежность системы. Ошибки не попадают на продуктовые сервера, пользователи с ними не сталкиваются, соответственно, растет их доверие к системе.

• У разработчиков баз данных отсутствует опыт в написании юнит-тестов. Тесты как сущность достаточно сильно отличаются от функций с логикой, к которым привыкли разработчики, поэтому внедрение юнит-тестов требует дополнительного обучения, освоения новых инструментов и навыков. 
  
• Существует мнение, что юнит-тесты на уровне баз данных — это неэффективно и слишком сложно.
  
• Не все понимают, как юнит-тесты могут повысить качество кода приложений и снизить риски.
  
• В командах бывают барьеры для внедрения нового или нет отклика на такую идею со стороны руководителя проекта и команды разработки.
  
• Если на проекте уже внедрены какие-то инструменты CI/CD, то не все они поддерживают нативную интеграцию с фреймворками для юнит-тирования. PostgreSQL сам по себе тоже может быть препятствием. 
  
• Естественно, на написание юнит-тестов тратится определенное время. Не все готовы на это идти.
  
• Часто есть фокус на других вариантах тестирования, например интеграционном и ручном. Безусловно, они также важны, у них свои цели и задачи, но они не заменяют юнит-тестов, а скорее дополняют их.

• Самый низкоуровневый слой — слой исходных данных.
  
• Бизнес-логика, т.е. сеттеры, которые рассчитывают данные и обновляют буферные таблицы, а также геттеры, извлекающие данные из этих таблиц для конкретных методик. Этот слой извне не видно.
  
• Парадный слой, где представлены геттеры, отдающие по запросу данные наружу. Именно к этому слою обращается фронт проекта и внешние пользователи.
  
• Самый верхнеуровневый — слой представления данных в удобном виде для бэкенда (JSON-ы, округление, цветовые показатели и т.п.).

• assert.ok(text) — размещается в конце тела тестовой функции, чтобы сообщить, что тест прошел успешно;
  
• assert.is_equal(IN have anyelement, IN want anyelement, OUT message text, OUT result boolean) — сравнивает два первых входных параметра и возвращает FAIL, если они не равны;
  
• assert.is_less_than(IN x anyelement, IN y anyelement, OUT message text, OUT result boolean) — сравнивает два первых параметра и возвращает FAIL, если первый более или равен второму.

• Разработка юнит-теста начинается с тест-плана, который оформляется в Confluence. Это своего рода спецификация тестирующей функции.
  
• Мы договариваемся не добавлять все возможные проверки сразу, чтобы был заметный прогресс в разработке юнит-тестов (иначе разработка одного теста будет занимать слишком много времени).
  
• Фичи юнит-тестов, добавляемые в последующие версии, не портируются в предыдущие юнит-тесты (также в целях ускорения разработки).
  
• Тестируем влияние входных параметров функций на результирующую таблицу, которую возвращает функция, и соответствие выходных параметров входным параметрам.
  
• В основном мы производим позитивное тестирование. Но сейчас уже начали добавлять по несколько негативных проверок в каждый юнит-тест. Например, вызываем функцию с пустыми входными атрибутами — при этом она должна оставаться стабильной и не падать.
  
• При проектировании автоматизированных проверок юнит-тестов мы опираемся на принципы тест-дизайна.

CREATE OR REPLACE FUNCTION unit_tests.example2()
RETURNS test_result
AS
$$
DECLARE
  message test_result;
  result boolean;
  have integer;
  want integer;
BEGIN
want := 100;
SELECT 50 + 49 INTO have;
SELECT * FROM assert.is_equal
(have, want) INTO message, result;

--Test failed.
IF result = false THEN
RETURN message;
END IF;
--Test passed.
SELECT assert.ok('End of test.') INTO message;
RETURN message;
END
$$
LANGUAGE plpgsql;
SELECT * FROM unit_tests.example2();

ASSERT FAILED : ASSERT IS_EQUAL FAILED.
Have -> 99
Want -> 100

3. unit_tests.example2() --> ASSERT IS_EQUAL FAILED.
Have -> 99
Want -> 100

• Red (тест падает);
  
• Green (тест прошел);
  
• Refactor (сохраняем работоспособность кода).

• тестирующая функция должна иметь имя: f_test_имя_тестируемой_функции();
  
• функции юнит-тестов должны возвращать тип значения test_result. По этому типу функция unit_tests.begin() находит все функции тестов в базе данных;
  
• функции юнит-тестов не имеют аргументов.

select test_schema.test_function();
все тесты через select:
select unit_tests.begin();

select t.*, d.*
from unit_tests.tests t
join unit_tests.test_details d
 on d.test_id = t.test_id
where started_on > current_date;

• Естественно, мы бы хотели покрыть юнит-тестами все запланированные на данный момент 183 функции (их общее количество — величина переменная).
  
• Параллельно у нас идет настройка CI/CD с сервера разработки на препрод. Планируем завершить ее в ближайшее время.
  
• Изначально мы не углубляемся в проверки — закрываем юнит-тестами самые критичные моменты. В будущем необходимо увеличить количество проверок.
  
• Хотим добавить проверки времени выполнения функций.
  
• Нужно вернуться — оптимизировать и отрефакторить уже написанные тесты.
  
• Планируем формировать культуру, где качество кода и тестирование являются приоритетными задачами для всей команды. Юнит-тесты в этом помогают. К тому же они служат дополнительной документацией с вариантами использования функции, что тоже немаловажно.