编写测试以检查runtimeerrors

Question

我正在为一个解释器编写测试，该解释器需要大量语法上有效的输入。这是我如何做的一个最小的例子：

package minimalexample

import (
    "testing"
)

func access(i int) string {
    return []string{"a", "b"}[i]
}

func TestAccess(t *testing.T) {
    tests := []struct {
        testdatum int
        expected  string
    }{
        {0, "a"},
        {2, ""},
        {1, "c"},
        {4, ""},
    }

    for _, tt := range tests {
        testAccess(tt, t)
    }
}

func testAccess(tt struct {
    testdatum int
    expected  string
}, t *testing.T) {

    defer func() {
        if err := recover(); err != nil {
        t.Errorf("Runtime error for testdatum %v: %q", tt.testdatum, err)

        }
    }()
    result := access(tt.testdatum)
    if result != tt.expected {
        t.Errorf("%v evaluates to %q, though it should be %q", tt.testdatum, result, tt.expected)
    }

}

处理panic的想法来自https://golang.org/doc/entiful_go#recover，但是我不知道在测试中使用它是否像上面的示例中那样是一种好的做法，或者有某种原因，为什么在修复运行时错误之前，最好让测试失败。

这种设置的好处是，我可以看到所有TestCase会发生什么，即使其中一个会引起恐慌。我仍然犹豫不决地说这是一个好的解决方案的原因是，我不确定关心运行时错误是测试人员的工作，还是应该由开发人员处理，开发人员必须修复代码以使测试通过。另一个原因是，在运行了一系列这些测试之后，我从vscode中得到了一个消息，我不明白，但怀疑与彻底的延迟有关：“运行贡献的命令:'_vscode_delegate_cmd_kms3v2s2'失败了。”

Answer 1

我不认为在测试中恢复panic以更清晰地捕捉它有任何错误，除了它可能表明您（或包作者）使用panic进行正常错误处理的设计模式不佳。

参见https://go-proverbs.github.io/

别怕.

null

关键是恐慌应该少用，因为通常错误更合适。而且应该更少地使用恢复，因为恐慌意味着事情出了很大的问题，不太可能有任何方法来修复它。

因此，您永远不应该使用panic，其目的是在典型使用下恢复panic。

再说一遍，这不是一个规则，它只是我在Go中错误处理的哲学

null

null