go - foo.go + foo_test.go的任何有用替代方法

Question

对于Go代码库的单元测试，foo.go和foo_test.go模式是否有合理的替代方法？唯一的“问题”是将所有这些额外文件都放在文件系统上的同一位置。将测试文件放在一个中央位置可能会很好，但是由于Go软件包的工作方式可能无法正常工作。

Answer 1

当您告诉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源文件都有一个单独的测试文件，您可以将所有测试放到一个测试文件中，并且测试文件可以比源文件更多。

在测试文件中，您可以使用相同的程序包名称，然后将测试文件与程序包一起编译，以便测试可以访问程序包中的所有内容(包括未导出的标识符)(白盒测试)。您可以使用后缀为_test的程序包名称，在这种情况下，这些文件中的测试将只能访问程序包的导出标识符(黑盒测试)。在此处阅读有关此内容的更多信息:How can I allow one package access to another package's unexported data only when testing?

您不必担心 .go文件的数量。即使您在一个软件包中有上千个 .go文件，该工具也会处理。尽管在大多数情况下，如果一个程序包中有许多 .go文件，则表明该程序包执行的过多，应将其拆分为多个较小的程序包。