Как писать unit-тесты для крупного приложения на go?

Question

[last7]

Допустим есть некое приложение по структуре похожее на это. То есть имеется несколько пложенных пакетов, включая controllers и его нужно протестировать.

Создаем *_test.go в пакете. Но проблема в том, что при инициализации приложения: создается мап шаблонов, подключение всяких сертификаты из файлов и тд. Пути в них относительные, поэтому если тест находиться в корне - все ОК, но если тест в пакете, из-за специфики запуска тестов в Go, корень запуска теста = путь пакета, они не загружаются. Нашел что я такой не один. Но оно до сих пор кажется мне не каноничным и не красивым.

Долго лазил по гихабу, но не нашел крупного веб-приложения хотя бы на 50% покрытым тестами.

От сюда возник вопрос: кто как тестирует вложенные пакеты, если в них есть зависимость открытия файлов? Да и вообще крупные приложения.

Спасибо

Comments

[Oleg Shevelev]

Ответ один - упрощайте.

[Oleg Shevelev]

И контролируйте директорию от которой читаете файлы.

[Евгений Иваха]

Перечитал вопрос снова.
Кто мешает вычислять пути по-разному, в зависимости от того, запущены тесты, или это продакшн окружение?

Answer 1

[sim3x]

По определению, юнит-тесты тестируют свой кусочек и не смотрят на приложение вцелом и даже на модуль. Они должны мокать все внешние запросы и подсовывать заранее определенные ответы

А функциональный тест вполне можно и в корень проекта положить

Answer 2

[Евгений Иваха]

Есть несколько подходов.
Один из них – тестировать только публичные методы пакетов, а файлы тестов держать в корне проекта.

Второй, и, мне кажется, более правильный – снижать связанность пакетов. Методы делать проще и более абстрактными, чтобы их было легче тестировать.

Comments

[last7]

Использую интерфейсы для получения данных из БД и подобных вещей, так что их можно заменить заглушками, но они довольно большие - половина текста теста будет составлять заглушка. А вот шаблоны в контроллерах, подключение к БД (в пакете бд) и тп все же как то нужно тестировать.

У вас нет живых примеров?

[Евгений Иваха]

В го примеров таких нет, к сожалению. Заглушки для БД можно и не делать большими, ведь ясно что они должны вернуть. Либо вообще тестировать с нормальной базой. В тесте прописать доступ к тестовому инстансу, например.

Шаблонизатор вообще незачем тестировать – это функционал сторонней библиотеки. Если она не работает, то нужно чинить её, а не ваш код.

Answer 3

[xabesawiv]

https://speakerdeck.com/mitchellh/advanced-testing...
Обсуждение на русском - тут
devzen.ru/episode-0095
В том числе и по интересующему вас вопросу.