对于 Go 代码库的单元测试，foo.go 和 foo_test.go 模式是否有任何合理的替代方案？唯一的“担忧”是将所有这些额外的文件放在文件系统上的同一位置。将测试文件放在中心位置可能会很好，但由于 Go 包的工作方式，这可能不起作用。
【问题讨论】：
foo_test包中的同一目录中，以支持黑盒测试同时保持测试有条理在被测代码旁边。
当你告诉go 命令测试一个包时，例如
go test some/path/mypackage
然后 go 工具将在包的目录中查找测试文件。如果你把测试文件放在别处，那么 go 工具将不会在其他文件夹中找到它们（它甚至不会查找它们），因此它们不会被运行/执行。
仅此论据就足以不将它们放在其他地方。
testing的包文档：
要编写新的测试套件，请创建一个名称以 _test.go 结尾的文件，其中包含此处所述的 TestXxx 函数。 将文件放在与被测试文件相同的包中。
Command go: Testing functions:
“go test”命令期望在与被测包对应的“*_test.go”文件中找到测试、基准和示例函数。
一些注意事项：
go 工具只希望测试文件在同一个文件夹中，但你可以随意命名它们，你只需要使用_test.go 后缀。例如。您可能有一个foo.go，并且您可以使用my_test.go 进行测试。也不需要为每个.go 源文件有一个单独的测试文件，您可以将所有测试放在一个测试文件中，并且您的测试文件可能比源文件多。
在测试文件中，您可以使用相同的包名，然后测试文件与包一起编译，因此测试可以访问包中的所有内容（包括未导出的标识符）（white-盒测试）。您可以使用以_test 为后缀的包名称，在这种情况下，这些文件中的测试将只能访问包的导出标识符（black-box 测试）。在此处阅读更多信息：How can I allow one package access to another package's unexported data only when testing?
您不必担心.go 文件的数量。即使您在一个包中有一千个 .go 文件，To go 工具也会处理。虽然在大多数情况下，如果一个包中有许多 .go 文件，这表明该包做得太多，应该将它分成多个更小的包。
【讨论】：
go test <filepath> => can't load package: package main: no Go files in (folder) 时出现此错误，所以这有点蹩脚 imo idk，知道解决方法吗？