golang-standards, тогда куда мне закинуть мокапы на интерфейсы? не в internal ведь, возможно другие пакеты будут тестироваться с помощью этих моков
Там где используются. Вы же не интерфейсы тестируете, а логику определенных компонентов.
да, но если есть несколько абстракций, которые используют один и тот же интерфейс и все они в разных пакетах/проектах, что делать?
Рядом с интерфесами не мокапами в интернал не?
Многовато зависимостей не?
да, но если требуется сохранить мокап для тестов в другом проекте? он то не сможет из интернала достать
ну можно и так сказать, но к сожалению лучше варианта не нашлось
Тогда просто рядом с основными кладите и не мучайтесь
А с другой стороны зачем моки экспортить?
интерфейсы определяются там, где они принимаются как параметры на вход функций. если у тебя отдельный пакет с мок-интерфейсами, добро пожаловать в ад (в будущем). Реализация интерфейсов для целей тестирвоания - делается прямо в test. Ну или в осмысленном пакете, если это не тест, в том числе, папкой в корне проекта.
В чем преимущество объявления интерфейса сервиса на уровне контроллера, относительно объявления его на уровне самого сервиса?
https://habr.com/ru/post/332948/ https://github.com/golang/go/wiki/CodeReviewComments#interfaces https://web.archive.org/web/20180214074802/ http://idiomaticgo.com/post/best-practice/accept-interfaces-return-structs/ https://mycodesmells.com/post/accept-interfaces-return-struct-in-go
Зачем мне эта куча ссылок?)
Это ответ на вопрос. Что не так?
Ответом на простой вопрос является куча ссылок?)
Чтобы их прочесть
Это фундаментальный вопрос языка
ну некой противоположностью моего предыдущего ответа может быть: так лучше. То есть ответ с минимальной агрументацией.
это простой вопрос только для тех, кто в курсе. для тех, кто не в курсе, он сложный. но можно и простой ответ дать: to reduce coupling
Дальше нужно объяснять про каплинг и кохижн))
Ну так я говорю не про все интерфейсы, а про конкретный вид - «управляющие», через которые вызывается бизнес-логика
Обсуждают сегодня