go 中的并行表驱动测试惨败

珍惜时间，勤奋学习！今天给大家带来《go 中的并行表驱动测试惨败》，正文内容主要涉及到等等，如果你正在学习Golang，或者是对Golang有疑问，欢迎大家关注我！后面我会持续更新相关内容的，希望都能帮到正在学习的大家！

我有以下测试功能

func testintegrationappswithproductionself(t *testing.t) {
    // here is where the apps array that will act as my test suite is being populated
    myapps, err := retrieveapps(fs)
    for _, v := range apps {
        v := v
        t.run("", func(t *testing.t) {
            t.parallel()
            expectedoutput = `=` + v + `
`
            cmpopts.singleapp = v
            t.logf("\t\ttesting %s\n", v)
            buf, err := varscmp(output, cmpopts)
            if err != nil {
                t.fatalf("error executing var comparison for %s: %s\n", v, err)
            }
            assert.equal(t, expectedoutput, buf.string())
        })
    }
}

测试失败，尽管当我删除 t.parallel() （甚至保留子测试结构）时它会成功。

失败（如前所述，仅当合并 t.parallel() 时才会发生）与传递给断言的要比较的值不同步有关，即 assert 方法比较它应该比较的值't）

这是为什么呢？ 我还执行了测试套件变量的神秘重新分配（v := v），我不明白）

编辑：徘徊如果是使用此包中的 assert 方法，我进行了以下替换，但最终结果是相同的，

    //assert.Equal(t, expectedOutput, buf.String())
    if expectedOutput != buf.String() {
        t.Errorf("Failed! Expected %s - Actual: %s\n", expectedOutput, buf.String())
    }

解决方案

让我们剖析一下这个案例。

首先我们参考the docs on testing.T.Run：

run 将 f 作为名为 name 的 t 子测试来运行。 它在单独的 goroutine 中运行 f <…>

（强调我的。）

因此，当您调用 t.run("some_name", somefn) 时，测试套件正在运行 somefn ，就像您手动执行类似操作一样

go somefn(t)

接下来，请注意，您没有将命名函数传递到对 t.run 的调用中，而是传递了一个所谓的函数文字；让我们引用 the language spec on them：

函数文字是闭包：它们可以引用周围函数中定义的变量。然后，这些变量在周围的函数和函数文字之间共享，并且只要可访问，它们就会一直存在。

在您的情况下，这意味着当编译器编译函数文本的主体时，它使函数“关闭”其主体提到的任何变量，并且该变量不是形式函数参数之一；在您的情况下，唯一的函数参数是 t *testing.t，因此每个其他访问的变量都由创建的闭包捕获。

在 go 中，当函数文字关闭变量时，它通过保留对该变量的引用来实现这一点 - 这在规范中明确提到为（“这些变量是 在周围函数和函数文字 < 之间共享…>»，再次强调我的。）

现在请注意，go 中的循环在每次迭代中重用迭代变量；也就是说，当你写

for _, v := range apps {

该变量 v 在循环的“外部”范围内创建一次，然后在循环的每次迭代中重新分配。回顾一下：同一个变量，其存储位于内存中的某个固定点，在每次迭代时都会被分配一个新值。

现在，由于函数文字通过保留对外部变量的引用来关闭外部变量，而不是在其定义的“时间”将它们的值复制到本身， — 如果没有那种看起来很时髦的 v := v “欺骗”，循环中每次调用 t.run 时创建的每个函数文字将引用循环中完全相同的迭代变量 v。
v := v 构造声明了另一个名为 v 的变量，该变量是循环体的本地变量，同时为其分配循环迭代变量 v 的值。由于局部 v “阴影”循环迭代器的 v，因此之后声明的函数文字将关闭该局部变量，因此每次迭代创建的每个函数文字将关闭一个不同的、单独的变量 v。

您可能会问，为什么需要这个？

之所以需要这个，是因为循环迭代变量和 goroutine 的交互存在一个微妙的问题，即 detailed on the Go wiki： 当一个人做类似的事情时

for _, v := range apps {
  go func() {
    // use v
  }()
}

创建一个结束 v 的函数文字，然后使用 go 语句运行它——与运行循环的 goroutine 以及在 len(apps)-1 其他迭代上启动的所有其他 goroutine 并行运行。 这些运行我们的函数文字的 goroutine 都引用相同的 v，因此它们都对该变量进行数据竞争：运行循环的 goroutine 写入它，而运行函数文字的 goroutine 读取它 来自它——并发且没有任何同步。

我希望，现在您应该看到拼图的各个部分拼凑在一起：在代码中

    for _, v := range apps {
        v := v
        t.run("", func(t *testing.t) {
            expectedoutput = `=` + v + `
            // ...

传递给 t.run 的函数文字在 v、expectedoutput 上关闭， cmpopts.singleapp （也可能是其他东西）， 然后 t.run() 使该函数文字在单独的 goroutine 中运行，如文档所述，在 expectedoutput 和 cmpopts.singleapp 以及其他任何不是 v 的内容（每次迭代上的新变量）或t（传递给函数文字的调用）。

您可以运行 go test -race -run=testintegrationappswithproductionself ./... 来查看参与的竞赛检测器使您的测试用例代码崩溃。

我将发布实际有效的内容，但是（除非问题已结束）我会接受实际详细说明的答案。

问题在于，用于存储 expectedoutput 的变量是通过 testintegrationappswithproductionself 函数内部但在 for 循环外部的声明来声明的（这现在反映在初始问题的代码片段中）。

有效的方法是删除 var expectedoutput string 语句并在 for 循环中执行

for _, v := range apps {
        v := v
        expectedOutput := `=` + v + `
`
        t.Run("", func(t *testing.T) {
            t.Parallel()
            cmpOpts.SingleApp = v
            t.Logf("\t\tTesting %s\n", v)
            buf, err := VarsCmp(output, cmpOpts)
            if err != nil {
                t.Fatalf("ERROR executing var comparison for %s: %s\n", v, err)
            }
            //assert.Equal(t, expectedOutput, buf.String())
            if expectedOutput != buf.String() {
                t.Errorf("Failed! Expected %s - Actual: %s\n", expectedOutput, buf.String())
            }
        })
    }

本篇关于《go 中的并行表驱动测试惨败》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！