仅在测试文件中引用的 go test 代码会被编译成二进制文件吗？答案

【问题标题】：Will go test code only referenced in test files be compiled into the binary?仅在测试文件中引用的 go test 代码会被编译成二进制文件吗？
【发布时间】：2017-11-24 21:29:18
【问题描述】：

我想知道如果您使用 go build ./... 编译二进制文件，将会将哪些代码编译到 go 二进制文件中。这将编译具有 cli 程序的二进制文件。对于这个 cli 程序，我有测试代码和非测试代码。我目前有几种类型的测试代码：

foo_test.go 包装内foo_test
foo_internal_test.go 包装内foo
testutil.go 在包testutil 中，提供测试实用功能

在非测试代码中实际上没有引用任何测试代码。 testutil 函数仅在测试文件中导入。

如果测试代码实际上被编译成二进制，这有多大问题？

【问题讨论】：

你指的是什么二进制文件？如果您不构建测试二进制文件，则不会编译 *_test.go 文件，因此它们不仅在链接期间被消除，而且根本不会被编译。
我希望能澄清这个问题
*_test.go 文件仅包含在指定包中的 go test 命令中。否则，编译器甚至都不会看到。
顺便说一句，您不能使用go build ./... 编译二进制文件，即构建通配符中包含的所有包，然后丢弃所有编译的对象。

标签： testing go compilation

【解决方案1】：

go 二进制文件仅包含可从其main() 入口点访问的代码。对于测试二进制文件，main() 是测试运行器。

至于“有多大问题”，如果它被包括在内……没有。它会在一定程度上增加二进制文件的大小和编译时间，但不会产生任何影响 - 根据定义，未执行的代码什么也不做。

【讨论】：

有趣的边缘情况是在使用辅助函数进行测试时。这些助手可以导入额外的包。当您仅测试依赖项时，它可能会对 prod 与测试代码的大小产生显着差异。我同意，Go 应该消除所有死代码。但最好明确一点，而不是依赖魔法。

【解决方案2】：

我相信如果你在一个无法访问的文件中有一个 init() 函数，它仍然会被链接到可执行文件中。

_test.go 文件仍将被排除。

当我们有一些不在 _test 文件中的测试助手代码时，这让我们感到很困惑。一个有一个在可执行启动时运行的 init() 函数。

【讨论】：