php小编百草今天为大家介绍一种测试覆盖率的方法。在软件开发过程中，测试覆盖率是一项重要的指标，它可以帮助我们评估测试用例对于代码的覆盖程度。而如果发现有语句未被覆盖到，我们可以通过一些手段来解决这个问题。在本文中，我们将探讨如何测试覆盖率以及如何处理未覆盖的语句。

问题内容

我有一个名为 setupConfig() 的 go 函数，并且我有一个 Test_setupconfig 来测试它并测试它很好。但是当我对其进行覆盖测试并查看 HTML 报告时，它显示我对 Viper 包返回的一些错误的处理没有被覆盖。为什么没有涵盖这一点？我该如何处理？

解决方法

覆盖率报告告诉您在测试期间执行了多少代码。您看到的是这些 if 块中的 return 语句未经过测试，这意味着您没有任何旨在失败并返回错误的单元测试。在测试您的代码在给定正确输入时是否有效的同时，确保在给定错误输入时测试正确且安全地失败也很重要。

但是，这是一个奇怪的情况，因为这些错误不在您自己的包中，这些错误来自 viper 包。此时，重要的是要问自己一个问题“我真正测试的是什么？”。如果您使用 viper 包，那么假设该包经过了彻底的测试，并且通过为 viper 错误创建您自己的测试，您只是在这些测试上加倍，而没有真正的改进。出于这个原因，有时我们选择省略测试这些分支，因为实际上，如果 viper 包错误 - 并假设您的所有输入都是静态的并且像所示的那样进行硬编码 - 那么这不是您的代码的问题，而是 viper 库的问题。

如果您真的想要获得 100% 的覆盖率并测试所有决策树，唯一的方法是将 viper 包放在某种抽象后面。最有可能的是传递到函数中的接口，允许多种实现，无论您是在生产中运行还是在测试中运行。

话虽如此，不建议像这样对函数中的所有值进行硬编码。理想情况下，您希望配置结构的值来自本地配置文件、环境变量、命令行标志或它们的组合。通过这样做，您可以让此设置函数接受用于检索配置的接口，从而使该函数易于测试，因为您需要做的就是在测试中模拟该接口的实现。所以它会像下面这样：

config.go：

type ConfigController interface {
    GetInput() Config
}

func setupConfig(controller ConfigController) error {
    config := controller.GetInput()
    // your code here
}

config_test.go：

type mockConfigController struct {}

func (m *mockConfigController) GetConfig() Config {
    return Config{
        // your config here
    }
}

func Test_setupConfig(t *testing.T) {
    configController := &mockConfigController{}
    err := setupConfig(configController)
    // rest of test here
}

通过这样做并为您的 setupConfig() 函数提供接受接口，这意味着您可以在生产中运行时为其提供函数实现，而且在运行测试时也可以使用硬编码的测试数据来模拟它。在与其他服务（例如数据库）交互时，也经常使用它。您可以让代码接受一个接口，告诉它如何与数据库交互并在测试中模拟它，而不必在运行测试时启动数据库并连接到它。这使您可以隔离部分代码并仅测试您想要的内容。