英文:
How to maintain good Go package test coverage when dealing with obscure errors?
问题
我正在尝试在一些Go包中保持100%的代码覆盖率。虽然在一些测试中我使用了-integration的构建标签来选择一些测试，但这在所有地方都不可行，但对于相对独立的库包来说应该是可能的。
然而，我在处理一些复杂错误路径的覆盖率时遇到了问题。
以下是一个示例，其中包含一个在集成测试中使用真实文件系统的方法：
func (idx Index) LoadPost(title string) (*PostSpec, string, error) {
postFolder := strings.Replace(strings.ToLower(title), " ", "_", -1)
spec, err := idx.getSpec(postFolder)
if err != nil {
return nil, "", err
}
f, err := os.Open(path.Join(idx.blogdir, postFolder, "content.html"))
if err != nil {
return nil, "", err
}
defer f.Close()
b, err := ioutil.ReadAll(f)
if err != nil {
return nil, "", err
}
return spec, string(b), nil
}
这是在go tool -cover中的显示效果：
很难触发这个代码块。我无法想到除了创建一个特殊的测试目录，其中要打开的文件不是常规文件之外的任何其他方法。这似乎会增加很多复杂性。
这本身并不是太大的问题，但这意味着我必须记住97.3%的覆盖率是正确的数字。如果我看到这个数字下降，是表示我的测试出了问题，有更多的未覆盖代码？还是表示我通过简化和删除死代码改进了我的包？这会导致我犹豫不决。
对于一些人来说，更重要的是，在业务环境中，这是一个构建仪表板的障碍。
英文:
I'm trying to maintain 100% code coverage on some of my Go packages. This isn't viable everywhere, even with some tests that I select with a -integration build tag on a build system, but it should be possible for my relatively isolated library packages.
I'm having trouble dealing coverage for obscure error paths, though.
Here is an example of one of my methodss that's part of an integration test where there's a real filesystem:
func (idx Index) LoadPost(title string) (*PostSpec, string, error) {
postFolder := strings.Replace(strings.ToLower(title), " ", "_", -1)
spec, err := idx.getSpec(postFolder)
if err != nil {
return nil, "", err
}
f, err := os.Open(path.Join(idx.blogdir, postFolder, "content.html"))
if err != nil {
return nil, "", err
}
defer f.Close()
b, err := ioutil.ReadAll(f)
if err != nil {
return nil, "", err
}
return spec, string(b), nil
}
Here's what it looks like in go tool -cover:
Hitting that block is not easy. I can't think of any way to do it other than creating a special test directory where the file it's trying to open is something other than a regular file. That seems like a lot of complexity.
This isn't too much of a deal on its own, but it means that I have to remember that 97.3% coverage is the right figure. If I see that number go down, does it mean I've broken my tests and there's now more uncovered code? Or just that I've managed to improve my package through simplification and removal or dead code? It leads to second guessing.
More importantly to some, in a business context it's an obstacle to a nice build dashboard.
答案1
得分: 5
io/ioutil/ioutil_test.go通过使用一个不存在的文件调用ioutil.ReadFile()函数来测试该错误。
这不需要任何设置。
filename := "rumpelstilzchen"
contents, err := ReadFile(filename)
if err == nil {
t.Fatalf("ReadFile %s: 预期出现错误，但未找到", filename)
}
英文:
io/ioutil/ioutil_test.go does test that error simply by calling ioutil.ReadFile() function with a non-existing file.
That shouldn't require any setup.
filename := "rumpelstilzchen"
contents, err := ReadFile(filename)
if err == nil {
t.Fatalf("ReadFile %s: error expected, none found", filename)
}
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论