unit-testing - Go 中良好的单元测试

Question

我一直认为好的单元测试，都是独立的测试。 “独立”是指当函数“A”使用“B”时，我们测试函数“A”时，我们模拟/ stub “B”以防“B”无法正常工作时它不会使“A”失败.

但是当我们检查 golang 包的来源时，这个原则是不被尊重的。

例如，让我们检查 url 包中的 url.go 和 url_test.go:

url.go:

func parseQuery(m Values, query string) (err error) {
    for query != "" {
    ...
    key, err1 := QueryUnescape(key)
    ...

url_test.go:

func TestParseQuery(t *testing.T) {
    for i, test := range parseTests {
        form, err := ParseQuery(test.query)
        ...

我们可以看到 parseQuery 使用 QueryUnescape。在测试中，QueryUnescape 没有以任何方式 stub 。因此，如果 QueryUnescape 会出错，parseQuery 测试就会失败。

所以包的作者并不总是满足“独立”单元测试的要求。在这种情况下不考虑这个原则的原因是什么，是否有一些规则允许程序员接受这种形式的单元测试？

在用 python 编写独立测试后，我对编写完美测试(这在 golang 中对代码设计有很大影响)和结果之间的平衡感到困惑。

Answer 1

您的问题实际上是关于在“单元测试”时定义“单元”的范围，这可能很棘手。 “单元”不一定表示函数或结构。这可能意味着一些功能/结构一起工作。但这肯定意味着您不会跨越进程边界(例如使用真实文件系统或通过网络访问数据库等)。边界通过集成测试进行测试或使用测试替身(模拟、 stub 、 spy 等)进行模拟。

我是 GoConvey 的作者，一个建立在内置 go “测试”包之上的测试工具。 GoConvey 有一套全面的单元测试。在tests for the core of the project我不会编写调用每个导出和非导出函数的测试。我在编写测试时考虑了面向公众的 API(导出的函数/结构)。该 API 的实现不是我的单元测试所关心的，但结果才是。你可以通过阅读一些测试来理解我的意思。我只调用了几个面向公众的方法并断言结果是正确的。实际上调用了很多结构和函数，但该包中的测试覆盖率非常高(目前为 92.8%——虽然没有我想要的那么高，但已经相当不错了)。

在 GoConvey 中的 convey 包的情况下，单元是整个包及其组件。一开始，我记得测试更加精细，这让我能够更快地进入红-绿-重构循环。随着代码的增长，那些范围较小的测试被似乎更合适的范围更广的测试所取代。因此套件将随着生产代码而发展。如果直接测试每个方法，您会感到很多摩擦和惰性，因为如果不破坏一堆测试，您将无法更改任何内容。

这是关于如何辨别单元测试范围的另一个有趣的总结:

http://blog.8thlight.com/uncle-bob/2014/01/27/TheChickenOrTheRoad.html