提高 Golang 代码覆盖率的执行步骤

为了提高 Golang 包 lxkns 的代码覆盖率，本文提出了一种解决方案，该解决方案涉及在被测程序内启用代码覆盖率，并将子进程写入的覆盖率数据附加到父进程的覆盖率数据中。该解决方案利用了 Go 的 testing 包中 coverreport() 函数，它将覆盖率数据写入 ASCII 文本格式文件。通过封装 testing.m 并检测它是否在启用覆盖率的情况下运行，该解决方案能够从重新执行的子进程中收集覆盖率配置文件数据文件，并将其合并到父进程的覆盖率配置文件数据文件中。这种方法允许覆盖那些通常无法通过常规测试运行报告的函数的代码覆盖率。

为了在某些条件下发现 linux 命名空间，我的开源 golang 包 lxkns 需要将其用作新子进程的应用程序重新执行，以便能够在 golang 运行时启动之前切换挂载命名空间。 linux 挂载命名空间的工作方式使得在运行时启动操作系统线程后无法将它们从 golang 应用程序切换。

这意味着原始进程“p”作为子进程“c”（重新执行包）重新运行自身的副本，通过子进程的环境传递特殊指示，向子进程发出信号仅运行特定的“操作” ”函数属于包含的“lxkns”包（详细信息请参见下文），而不是正常运行整个应用程序（避免无休止地递归生成子项）。

forkchild := exec.command("/proc/self/exe")
forkchild.start()
...
forkchild.wait()

目前，我从 visualstudio code 调用覆盖率测试，它运行：

go test -timeout 30s -coverprofile=/tmp/vscode-goxxxxx/go-code-cover github.com/thediveo/lxkns

因此，“p”重新执行自身的副本“c”，并告诉它运行某个操作“a”，将一些结果打印到标准输出，然后立即终止。 “p”等待“c”的输出，解析它，然后继续其程序流程。

模块测试使用 ginkgo/gomega 和专用的 testmain 来捕获测试何时作为子项重新执行，以便仅运行请求的“操作”函数。

package lxkns

import (
    "os"
    "testing"

    . "github.com/onsi/ginkgo"
    . "github.com/onsi/gomega"
    "github.com/thediveo/gons/reexec"
)

func TestMain(m *testing.M) {
    // Ensure that the registered handler is run in the re-executed child. This
    // won't trigger the handler while we're in the parent, because the
    // parent's Arg[0] won't match the name of our handler.
    reexec.CheckAction()
    os.Exit(m.Run())
}

func TestLinuxKernelNamespaces(t *testing.T) {
    RegisterFailHandler(Fail)
    RunSpecs(t, "lxkns package")
}

我还想从重新执行的子进程创建代码覆盖率数据。

• 是否可以在被测程序本身内启用代码覆盖率，如何实现？
• 是否可以将子进程写入的代码覆盖率数据附加到父进程“p”的覆盖率数据中？
• golang 运行时是否仅在退出时写入覆盖率数据并覆盖指定的文件，还是追加？ （我已经很高兴能有一个指向相应运行时源的指针。）

注意：在我的测试用例中，切换挂载命名空间不会与在新挂载命名空间中创建覆盖文件发生冲突。原因是这些测试挂载命名空间是初始挂载命名空间的副本，因此创建新文件也会正常显示在文件系统中。

解决方案

在 @volker 对我的 q 发表评论后，我知道我必须接受挑战，并直接获取 go 的 testing 包的源代码。虽然 @marco.m 的建议在许多情况下很有帮助，但它无法处理我承认的有点奇怪的用例。与我原来的问题相关的 testing 的机制如下，已大大简化：

• cover.go：实现 coverreport()，它写入覆盖率数据文件（ascii 文本格式）；如果文件已经存在（上次运行的陈旧版本），那么它将首先被截断。请注意，coverreport() 有一个恼人的习惯，即向 os.stdout 打印一些“统计”信息。
• testing.go：
  • 从 os.args 获取 cli 参数 -test.coverprofile= 和 -test.outputdir= （通过 flags 包）。如果还实现了 tooutputdir(path)，则将覆盖配置文件放置在 -test.outputdir 内（如果指定）。
  • 但是 coverreport() 何时被调用？简单来说，在testing.m.run()的末尾。

现在有了这些知识，疯狂的解决方案开始出现，有点“变坏”；）

• 将 testing.m 封装在一个特殊的重新执行启用版本 reexec.testing.M 中：它检测它是否在启用覆盖的情况下运行：
  • 如果它是“父”进程 p，则它会正常运行测试，然后从重新执行的子进程 c 收集覆盖率配置文件数据文件，并将它们合并到 p 的覆盖率配置文件数据文件中。
  • 在 p 中，当即将重新执行新的子 c 时，将为子 c 分配一个新的专用覆盖率配置文件数据文件名。然后 c 通过其“个人”-test.coverprofile= 获取文件名cli 参数。
  • 在 c 语言中，我们运行所需的操作函数。接下来，我们需要运行一个空测试集，以便触发写入 c 的覆盖率配置文件数据。为此，p 中的重新执行函数添加了一个 test.run= ，其中包含一个非常特殊的“Bielefeld 测试模式”，它将最有可能导致空结果。请记住，p 将在运行所有测试后选取各个 c 覆盖率配置文件数据文件并将它们合并到 p 中。
• 如果未启用覆盖率分析，则无需采取特殊操作。

该解决方案的缺点是，它依赖于 go 的 testing 的一些不受保证的行为，涉及如何以及何时编写代码覆盖率报告。但由于 linux 内核命名空间发现包已经对 go 的推动力可能比 docker 的 libnetwork 还要大，所以这只是一个远远超过边缘的量。

对于测试开发人员来说，整个 enchilada 隐藏在“增强型”rxtst.m 包装器中。

import (
    "testing"
    rxtst "github.com/thediveo/gons/reexec/testing"
)

func TestMain(m *testing.M) {
    // Ensure that the registered handler is run in the re-executed child.
    // This won't trigger the handler while we're in the parent. We're using
    // gons' very special coverage profiling support for re-execution.
    mm := &rxtst.M{M: m}
    os.Exit(mm.Run())
}

运行整个 lxkns 测试套件并覆盖，最好使用 go-acc（进行精确的代码覆盖率计算），然后在下面的屏幕截图中显示函数 discovernsfsbindmounts() 运行了一次 (1)。该函数不是直接从 p 中的任何位置调用的。而是注册该函数，然后在重新执行的子 c 中运行。以前，没有报告 discovernsfsbindmounts() 的代码覆盖率，但现在借助包 github.com/thediveo/gons/reexec/testing c 的代码覆盖率透明地合并到 p 的代码覆盖率中。

好了，本文到此结束，带大家了解了《提高 Golang 代码覆盖率的执行步骤》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！