提案详情
我创建了 https://go-review.googlesource.com/c/go/+/564995 和 https://go-review.googlesource.com/c/go/+/564576 ,在这个过程中，发现了一种方法来寻找可能值得并行运行的测试，这可以通过 go test 自动完成。
这种方法是 go test -v 获取每个测试的运行时间，然后排除已经并行运行过且运行时间较短的测试，剩下的就是可能值得并行运行的测试。
例如：
从 go test -v runtime 获取
=== RUN TestSmhasherTwoNonzero
--- PASS: TestSmhasherTwoNonzero (9.09s)这可以确定 TestSmosherTwoNonzero 可能值得并行运行。
然而，基于在上述 CL 中获得的经验，go test 更方便地执行此搜索。
因为可能有很多测试，可能会有日志和跳过输出，而且使用 go test 进行此查找有明确的规则。
具体提案内容
添加一个名为未确定的标志，暂时使用 maybeparallel 作为占位符，go test -maybeparallel 仅提供此语义，报告可能值得并行运行的测试。
实现这一点的一种方法是输出未并行运行且运行时间超过 0.4 秒的测试的名称和时间。
值得讨论的：
也许还应该添加一个标志，设置在一定时间内未完成的测试，go test -maybeparallel 仅输出这些测试的名称和运行时间。
4条答案
按热度按时间eiee3dmh1#
这是一个有趣的想法，
-maybeparallel应该分析可以静态并行运行的测试吗？例如，它不会报告修改全局状态的测试，但会报告一些仅修改局部对象的测试。
esyap4oy2#
go test -maybeparallel静态分析和运行测试后的分析的优缺点如下：静态分析的优点是避免了报告全局状态更改的测试，这些更改通常不应该并行化，例如 runtime_test.TestChan。缺点是静态分析需要判断测试运行所需的时间，如果测试运行所需的时间非常小，可能不值得并行化，从而使实现变得更加复杂。可以通过运行测试运行来确定测试运行所需的时间，无需分析代码。
运行测试后进行分析的优点是实现简单，实现方式可以是确定在运行测试后所花费的时间是否超过了某个限制。缺点是可能会报告一些改变全局状态的测试。请注意
go test -maybeparallel只提供这种语义，它报告了可能值得并行运行的测试。我认为任何能够提供这种语义的实现都是可以接受的。ymzxtsji3#
每个对T.Parallel的调用都是测试维护者对所有其他标记为Parallel的测试的并发安全性的Assert。如果没有这个Assert，测试运行器必须假设测试不是并发安全的，这种情况经常发生。
在我看来，邀请用户并行运行未设计为并发安全的测试似乎有点像邀请他们测试已拆除安全带、刹车和气囊以减轻重量的汽车的最高速度。更快但不安全并不符合Go的方式。
@Jorropo 它不会报告修改全局状态的测试，但会报告一些仅修改局部对象的测试。
我认为在当前静态分析技术的状态下，这在实际操作中是不可行的。
jq6vz3qz4#
这个提案并不是邀请用户运行那些未设计为并行安全的测试，而是帮助用户找到可能值得并行化的测试。
在包含大量测试的包(如runtime)中，手动分析go test -v以找到可能值得并行运行的测试并不容易，因为存在太多无效信息，例如一个运行了0.00s的测试。
如果应用程序能够识别出可能值得并行运行的测试，开发者就可以将节省的能量用于研究这些测试是否应该并行运行，而不是在一堆无效信息中花费精力寻找有效信息。
这个提案的理想用例：
go test -maybeparallel(标志名未确定，暂时使用maybeparallel作为占位符)
排除类似runtime.TestChan这样的不应该并行运行的测试，因为
defer runtime.GOMAXPROCS(runtime.GOMAXPROCS(4))或其他原因。找到像runtime.TestSmhasherTwoNonzero这样的可以并行运行、值得并行运行的测试，没有并行测试。