gpt4 book ai didi

unit-testing - Go 单元测试 fatal error 和测试 main()

转载 作者:IT王子 更新时间:2023-10-29 01:52:35 25 4
gpt4 key购买 nike

我对使用 PHPUnit 测试的 PHP 背景进行测试还很陌生。

在 PHP 中,您需要 100% 的覆盖率这一说法非常可靠。在 Go 中,我读到的关于测试的大部分内容似乎都很少,没有诸如引发错误之类的内容。

比如我的小程序:

func main() {
config = readConfig("config.json")
}

func readConfig(path string) Config {
var cfg Config
file, err := ioutil.ReadFile(path)
if err != nil {
log.Fatal(err)
}
err = json.Unmarshal(file, &cfg)
if err != nil {
log.Fatal(err)
}
return cfg
}

func TestCanReadConfig(t *testing.T) {
cfg := readConfig("test_data/config.json")
if cfg.Broker_pass != "test" || cfg.Broker_port != "3333" {
t.Error("invalid config")
}
}

现在在我的示例中,我会遇到覆盖问题,因为单元测试中根本没有涵盖 main()(应该如何?)

并且根本没有涵盖 2 个 log.Fatal()。

我的问题是如何准确地在 go 中编写测试?我是不是以一种不太严格的风格来做,而不是测试每一个可能的场景,或者我可以像在 php 中那样做注释吗?@expectedException\InvalidArgumentException我可以或应该测试主要功能吗?如果不能,我能以某种方式从覆盖工具中忽略它吗?我应该考虑一个测试框架吗?大多数测试教程都很好但很短,并且只介绍简单的测试。

最佳答案

它本身不是 Go 的东西,它取决于你的偏好,但是:

一个。不要测试 main。 main 应该只调用经过测试的代码,最好是在其他包中。为这些包提供尽可能多的代码覆盖率,并尽可能让 main 变得微不足道。无论覆盖范围如何,这都是一个很好的做法。所以这不是真正的问题。

不要将 log.Fatal 用于可测试代码,只返回错误。您可以将 log.Fatal 保留在应用程序初始化代码中,即 - 在 main 中:)。因此,如果 main 调用 readConfig 并且它失败了,它只会返回一个错误(非常可测试!)。 log.Fatal 添加的应用程序行为是 main 的工作——配置读取器不应该处理诸如决定我们是否应该退出应用程序之类的事情,对吧?它只是读取配置并告诉您它是否成功。应用程序决定如何处理它。

因此您的代码可能如下所示:

func readConfig(path string) (Config, error) {
var cfg Config
file, err := ioutil.ReadFile(path)
if err != nil {
return cfg, err
}
err = json.Unmarshal(file, &cfg)
if err != nil {
return cfg, err
}
return cfg, nil
}

func main() {
config, err := readConfig("config.json")
if err != nil {
log.Fatal(err)
}

}

现在您已经将逻辑与应用程序行为分开,并且 readConfig 是完全可测试的。

关于unit-testing - Go 单元测试 fatal error 和测试 main(),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37907679/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com