测试基础 【译】你相信从不失败的测试吗?

黑水 · 2021年01月25日 · 最后由 黑水 回复于 2021年02月01日 · 3394 次阅读

原文:Do you trust a test that you have never seen fail

最近 David Heinemeier Hansson(dhh)写了一篇 “TDD 已死,测试万岁” 的博文。他描述了 TDD 世界如何变得刻薄,也许它曾经被用来打破自动化测试和回归测试的边界,但现在已经不是这样了。(我有点同意这个观点,但有很多人很生气)

然后他宣称自己已经受够了,宣称自己不先写测试了并以此为荣。

这个帖子显然让人褒贬不一。我在 twitter 上关注了很多强力拥护 TDD 的顾问类型的人,他们说 dhh 不应该这样说。他们一直在争论因为底层架构不允许,测试 rails 应用有多难(在我看来,这偏离了论点)。David 简单的说明了我们不应该武断行事,这是每个人都应该遵循的合理建议。就像不应该在没有意义的情况下遵循最佳实践。

然后大肆宣扬自己不先写测试并以此为荣的人很快多了起来。我觉得这种情绪挺让人担心的。为什么这么说呢?

你怎么能相信从不失败的测试?

如果当你提交代码时要运行成千上万的测试,你会希望有很大可能发现所有退化。写完代码后再写测试会导致很多测试可能永远不会失败,这就会占用大量的资源,耗费大量的金钱。在今年年初,Mozilla 每次推送代码到 Mozilla Inbound(存放 Firefox 代码的主树)都会耗费 200 个计算小时。这么多的资源浪费在不知道能发现什么的测试上。仅供参考,有很多永远发现不了问题的测试在 Mozilla 树里,但很难知道是哪些:(。

我知道你不可能总是先写一个测试, 有的时候这样做是相当困难的, 但你能做的最重要的事情是确保你可以相信你的测试,确认它们真正做到你所期望的事。

dhh 确实说过,不是所有的东西都可以进行单元测试,我想这是这个议题的关键。在我看来,他和其他很多人都被测试的归类所困扰。这就使他们先不写测试了。我一直是 Google 归类测试的方式的忠实粉丝。用描述做了多少工作替代了 TDD 的死板信条。这就是我们应该做的事情!!!

所以,如果你准备不先写测试,首先要确保你可以相信你写的测试,你的同事也可以信任你写的测试!

译注:这篇 2014 年的文章内容并不丰富,不过这两年看到太多次 “做自动化测试不是为了发现 bug” 的说法,也有很多重度依赖覆盖率这种虚荣指标的事。所以还是有再读的价值的~~

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 6 条回复 时间 点赞

这是自动化用例腐败的典型现象

从不失败的不叫测试了吧,或许可以叫 保障?

单单强调自动化测试覆盖率,除了年终总结,没有太大的意义。

def add_one(num)
    return 2
end

def test_add_one()
    raise 'wrong result' unless add_one(1) == 2
end

这样代码覆盖率很高的

恒温 回复

有时候诞生的那一刻就是腐败的😅

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册