Проблема с разрешением относительных путей в неосновном пакете - PullRequest
Новая
       16

Проблема с разрешением относительных путей в неосновном пакете

0 голосов
/ 11 марта 2019

У меня проблемы с разрешением относительных путей к файлам в приложении Go. Для этого приложения я решил сделать пакет, который предлагает единый интерфейс для различных файлов конфигурации. Пакет conf содержит соответствующие файлы данных, так что в основном это дерево файлов: 

app/conf
    + config.go
    + config.json
    + ...
app/code
    + code.go
    + code_test.go

Проблема в том, что когда тесты, определенные в app/code/code_test.go, вызывают функцию в пакете app/conf, который, в свою очередь, пытается открыть app/conf/config.json, относительный путь путается, так как рабочий каталог находится в app/code.

  • Я рассмотрел другие ответы SO, в которых упоминается пакет path/filepath и особенно функция filepath.Abs для преобразования относительных путей в абсолютные. Однако это не решит мою проблему, поскольку абсолютный путь будет основан на неверном рабочем каталоге .

  • Некоторого решения с "абсолютными путями" , основанного на GOPATH, вероятно, будет достаточно, но я думаю, что GOPATH не будет иметь большого значения, когда код будет создан и экспортирован.

  • Простое портирование всех файлов конфигурации в жестко запрограммированные структуры Go также нецелесообразно, так как они используются на разных языках.

1 Ответ

1 голос
/ 11 марта 2019

Использование пути к файлу конфигурации в исходном коде является проблемой не только в модульных тестах, но и в производственной. Как правило, код будет выглядеть примерно так:

  • Обработчик конфигурации принимает io.Reader, с которого он будет считывать конфигурацию.
  • main откроет файл (путь которого может быть жестко задан, передан в командной строке, передан env var и т. Д.) И передан в обработчик конфигурации для чтения.
  • Юнит-тесты обработчика конфигурации вместо этого жестко закодируют конфигурацию (или несколько конфигов, чтобы протестировать различные сценарии) во что-то вроде bytes.Buffer и передают это в обработчик конфигурации для чтения.
  • Модульные тесты всего, кроме кода, который читает файл конфигурации (то есть все, что использует конфигурацию, но не манипулирует этим), сгенерирует структуру Config в коде, а не читая его из реального или поддельного файла, как часть тестового набора. Например, myConf := config.Config{SomeProp: "foo", OtherProp: true}, а затем передать это тестируемой функции.
...