Pull to refresh

Comments 4

Кроме плюсов, тестирование с БД имеет и недостатки. Например:

  • снижает скорость тестов;

  • нагружает тестовый сервер;

  • приходится настраивать доп. окружение (docker, env и т.д.) для запуска тестов;

Если эти недостатки мешают, то можно использовать гибридный подход:

  • пишущий тесты с БД разработчик действительно запускает БД (например, как написано в этой статье). Но, запуская их специальным образом ( sqlmockgen -out=sql_test.go -db=${TESTING_DB_URL} .` ), еще и автоматически генерирует код mock-ов, заменяющих БД;

  • все прочие разработчики без заморочек (просто `go test ./...`) запускают тесты на mock-ах, чтоб только проверить, что ничего не поломалось;

Подробнее попытался изложить в песочнице: Кодогенерация для создания go-sqlmock'ов / Песочница / Хабр (habr.com)

Для тестирование БД создаю временную схему, и в конце теста `DROP SCHEME`, имя временной схемы генерирую случайным образом. В проекте держу SQL файл для инициализации БД.

нагружает тестовый сервер;

Не совсем понятно какой сервер, и почему это для нас проблема. В предлагаемом подходе используется СУБД на машине разработчика.

приходится настраивать доп. окружение (docker, env и т.д.) для запуска тестов;

Да, в начале внедрения нужно подготовить docker-compose.yml, Makefile и пакет вида testingpg, но потом вся настройка заключается только в установке docker и docker-compose, а дальше можно просто запускать тесты.

Перед первым запуском поднимаем окружение:

make test-env-up

Далее спокойно запускаем тесты через IDE или следующие команды:

make test
go test ./...

Без дополнительной настройки env и так далее.

Sign up to leave a comment.

Articles