Ответ 1
Хорошей моделью для проверки является исходный код самого Go: http://golang.org/src/pkg/
Вы увидите, что этот подход (разделение на основе таких элементов языка, как struct, interface,...) никогда не используется.
Все файлы основаны на функциях, и лучше всего использовать принцип принципа близости, где вы можете найти в том же файле определение того, что вы используете.
Как правило, эти функции группируются в один файл для каждого пакета, за исключением больших, где один пакет состоит из множества файлов (net, net/http)
Если вы хотите что-то отделить, отделите источник (xxx.go) от тестов/тестов (xxx_test.go)
Томас Джей Раш добавляет в комментарии
Иногда исходный код генерируется автоматически - особенно определения структуры данных.
Если структуры данных находятся в том же файле, что и код, созданный вручную, необходимо создать возможности для сохранения фрагмента, созданного вручную, на этапе генерации кода.
Если структуры данных разделены в другом файле, то включение позволяет просто написать файл структуры данных, не беспокоясь.
Дейв Чейни предлагает интересную перспективу в "Absolute Unit (Test) @LondonGophers" (март 2019 г.)
Вам следует шире взглянуть на тестируемое "устройство".
Единицы - это не каждая внутренняя функция, которую вы пишете, а целый пакет. В частности, публичный API пакета.
Хорошая идея - организовать ваши файлы, чтобы облегчить тестирование их публичного API.
В этом отношении accounts_struct_test.go не имеет особого смысла.
См. также "Как организовать пакеты в Go", автор Бартломей Климчак
Иногда требуется несколько обработчиков или репозиториев.
Например, некоторая информация может быть сохранена в базе данных, а затем отправлена через событие в другую часть вашей платформы. Хранить только один репозиторий с помощью метода, подобногоsaveToDb(), не очень удобно.
Все подобные элементы разделены по функциональности:repository_order.goилиservice_user.go.
Если существует более 3 типов объектов, они перемещаются в отдельную подпапку.