Проверено для sqlrs v0.1.1-rc.6Исходный код 1752abbb

Подключите существующие автотесты

Передайте тестам DSN воспроизводимого экземпляра и сохраните привычный способ запуска.

Цель интеграции

Не переписывайте существующую систему запуска тестов под sqlrs. Сделайте подключение к базе внешним параметром, создайте воспроизводимый экземпляр и передайте его DSN тестам тем же способом, которым проект уже получает секреты и настройки окружения.

1. Вынесите подключение в переменную окружения

Приложение или код настройки тестов должны читать, например, DATABASE_URL. Не храните выданный DSN в репозитории: экземпляр временный, а адрес относится только к конкретному локальному запуску.

2. Создайте экземпляр из сохранённого рецепта

Здесь test-db — alias, созданный в предыдущей главе для prepare-рецепта проекта. По умолчанию sqlrs prepare ждёт готовности экземпляра и печатает в стандартный вывод строку DSN=postgres://…. Удалите префикс DSN= перед передачей значения приложению.

PowerShell
$dsnLine = sqlrs prepare test-db
$env:DATABASE_URL = $dsnLine -replace '^DSN=', ''
pnpm test
POSIX shell
export DATABASE_URL="$(sqlrs prepare test-db | sed 's/^DSN=//')"
pnpm test

Замените pnpm test на существующую команду проекта: так можно запустить приложение, JUnit, pytest, Go tests или любой другой процесс, который умеет читать DSN. Если тесты работают параллельно, выберите уровень изоляции явно: отдельный экземпляр на параллельный процесс либо очистка данных и транзакции внутри одного общего экземпляра.

3. Удалите использованный экземпляр

После завершения тестов найдите экземпляр и удалите его по однозначному префиксу id:

sqlrs ls --instances
sqlrs rm INSTANCE_ID_PREFIX
СоветИспользуйте короткий однозначный ID

Для экземпляра достаточно первых восьми или более шестнадцатеричных (hex) символов, если такой префикс совпадает ровно с одним объектом. В таблице ls по умолчанию уже показаны 12 символов, поэтому обычно можно скопировать значение прямо из INSTANCE_ID.

4. Не создавайте схему заново в каждом тесте

  • Prepare-рецепт отвечает за схему и стабильные справочные данные.
  • Подготовка конкретного теста создаёт только данные своего сценария.
  • Тесты меняют экземпляр; исходное неизменяемое состояние остаётся нетронутым.
  • Повторный prepare того же рецепта может переиспользовать уже подготовленное состояние.

Одноразовые SQL-проверки

Если вся проверка выражается psql-скриптом, используйте одну составную команду:

sqlrs prepare test-db run:psql -- -f tests/db-smoke.sql

Экземпляр удаляется сразу после run. Встроенные run-режимы предназначены для psql и pgbench; универсального режима для произвольной команды на локальной машине нет. Приложению или обычной системе тестов передавайте DSN напрямую, как в примере выше.

Как улучшать существующий набор тестов постепенно

  1. начните с одного медленного интеграционного теста и одного prepare-alias;
  2. уберите из теста создание схемы, но оставьте подготовку данных и проверки результата;
  3. добавьте короткую проверочную команду в README проекта или систему сборки;
  4. после стабильного локального цикла повторите тот же путь в CI с поддерживаемыми контейнерами;
  5. измеряйте время отдельно у prepare, запуска экземпляра и самих тестов.
Кэш не очищает тестовые данные

Повторное использование состояния не делает тесты независимыми автоматически. Если несколько тестов делят один изменяемый экземпляр, их данные могут влиять друг на друга.

Добавьте проверку миграций в pull request

Сравните входные файлы между базовой ревизией и текущим коммитом.

Перейти к Git-сценариям