testingtesting
coverReport()coverReport()
-test.coverprofile=-test.outputdir=os.ArgstoOutputDir(path)-test.outputdir
coverReport()testing.M.Run()

现在有了这些知识，一个疯狂的解决方案开始出现，有点“变坏”；)
testing.Mreexec.testing.M
  • 如果它是“父”进程 P，那么它正常运行测试，然后它从重新执行的子进程 C 中收集覆盖率配置文件数据文件并将它们合并到 P 的覆盖率配置文件数据文件中。 
    • -test.coverprofile=
    test.run=
  • 如果未启用覆盖分析，则无需采取任何特殊操作。

    • 这个解决方案的缺点是它依赖于 Go 的 
    testing
    的一些不受保证的行为。关于它如何以及何时编写代码覆盖率报告。但由于 Linux 内核命名空间发现包已经比 Docker 的 libnetwork 更难插入 Go，这只是一个超出边缘的量子。

    对于测试开发人员来说，整个辣酱 Jade 米饼馅都隐藏在“增强版”
    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 的代码覆盖率中。