go版本开发+0175064e69 Thu Jan 3 05:07:58 2019 +0000 linux/amd64
如果一个包只能在测试模式下构建，go test成功，而go build/install失败：
// broken.go
package broken
var X typ// broken_test.go
package broken
import "testing"
type typ int
func TestX(t *testing.T) {
var _ typ = X
}如果一个人只开发一个包，go test是确保一切正常的主要手段，许多CIs只是运行go test,这意味着可以在不注意的情况下提交甚至无法构建的代码。
如果go test能确保一个包实际构建就更好了。
5条答案
按热度按时间5jvtdoz21#
/cc @bcmills@rsc
pieyvz9o2#
包内测试总是存在不真实的可能性。例如，如果
broken_test.go提供了一个init函数而不是类型声明，那么直到运行时其他测试中才会发现破坏性。相反，包外部测试(使用
package broken_test而不是package broken)会从一开始就捕获到这个例子。与其在不需要的地方添加“清理包构建”步骤，我更希望鼓励用户使用外部测试而不是包内测试。
另请参阅 #29258 。
xvw2m8pv3#
但是每个人都有很多使用未导出函数的测试。这将导致所有测试都失效，而
export_test.go技巧的使用相当不方便，最终它仍然是包内的_test.go文件。出于这些原因，我们始终建议采用相反的方法。我遗漏了什么/有什么变化？gmol16394#
但是每个人都有很多使用未导出函数的测试。我说的是“鼓励”，而不是“要求”。如果你想捕捉测试包和真实包之间的微妙差异，就针对真实包进行测试：这是你可以在今天做到的事情，而不需要
go命令提供任何额外的支持。我们总是推荐相反的做法。我错过了什么/发生了什么变化？
internal包使得在不向外部世界暴露它们的情况下定义(并针对)导出的API成为可能。我不知道官方的建议是什么，但至少对我来说，这抵消了对包内部测试的最有力的论据。avwztpqn5#
这似乎是帮助用户注意到的一个合理的事情。
我强烈反对默认使用外部测试。恰恰相反：我认为外部测试应该保留给内部测试会碰到导入周期的情况。
我想了解在一个典型的
go test周期中，构建带有和不带有其内部测试的包需要花费多少成本。我的猜测是它不会花费太多——go test大部分的成本在于链接二进制文件，而不是包本身的增量构建。