Go 解决非主包中的相对路径问题

我在解析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，所以相对路径混乱

我已经看过了其他提到path/filepath包的SO答案，特别是filepath.Abs，用于将相对路径转换为绝对路径。但是，这并不能解决我的问题，因为绝对路径将基于错误的工作目录

一些基于GOPATH的绝对路径的解决方案可能就足够了，但我认为在构建和导出代码时，GOPATH没有什么意义

简单地将所有配置文件移植到硬编码的Go结构是不可行的，因为它们是跨语言使用的

---

依赖源代码中的配置文件路径不仅是单元测试中的问题，也是生产中的问题。通常，代码会执行以下操作：

配置处理程序接受它将从中读取配置的io.Reader。 main将打开一个文件，该文件的路径可能是硬编码的、通过命令行传递的、通过env var传递的，等等，并将其传递给config处理程序进行读取。 配置处理程序的单元测试将改为硬编码一个配置或多个配置，以将不同的场景测试为bytes.Buffer之类的内容，并将其传递给配置处理程序进行读取。 除了读取配置文件的代码之外的任何东西的单元测试，因此，任何使用配置但不操纵配置的东西都会在代码中生成配置结构，而不是从真实或虚假的文件中读取，作为测试工具的一部分。例如，myConf:=config.config{SomeProp:foo，OtherProp:true}，然后将其传递给被测函数。

---

您是否仅在测试文件中存在此问题？我这样问是因为它们没有包含在最终构建中。因此，在您构建和部署应用程序后，将不会有code_test.go在app/conf中执行func…@mkopriva不抱歉，我不清楚，在上面的示例中，这些函数是从实际的imemmentation文件code.go调用的，但这些函数也将从实际的主包调用，也就是说，不仅仅是在测试中。然后您可以指示用户将配置文件安装在已知位置，无论是绝对位置还是相对于二进制位置，这都是您的决定。或者，您可以指示用户提供配置的位置，作为cli arg或env var，或两者都提供。。。。第三种选择是将配置嵌入最终的二进制文件中。go命令不支持这种开箱即用的方式，但是有第三方库可以为您做到这一点；e、 g.指导用户定义一些环境变量或类似的东西，但我想知道是否有更好的传统解决方案更适合本地使用。谢谢Adrian，回答得很好。我一直在寻找一种基于配置的动态测试方法，而不是在测试中显式地针对静态配置值进行测试，因为配置的大部分内容无论如何都会保持不变。但我想这背后的动机是方便，而不是其他任何东西。为了方便起见，你没有理由不能定义一个struct literal并在多个测试中重用它，甚至跨多个包。一些行为测试依赖于高度个性化的ICC配置文件，该配置文件是配置的一部分，并且适合运行测试的系统。因此，这些概要文件不能硬编码，以免测试套件变得极其脆弱。因此，虽然我认为我已经找到了一种方法，可以根据您的建议对系统的某些部分进行建模，但我很难看到如何在测试这些组件时避免动态配置。在不了解更多信息的情况下，我所能建议的就是将代码重构为不太特定于环境的代码，这样测试就不需要依赖于运行它的系统的概要文件。单元测试在任何系统上都应该是100%可复制的，没有系统特定的更改。好的，谢谢你的帮助。这些组件在屏幕上执行图像识别，需要一些基本测试，但这些测试不是也永远不会是正确的单元测试。