原文：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” 的说法，也有很多重度依赖覆盖率这种虚荣指标的事。所以还是有再读的价值的~~
这是自动化用例腐败的典型现象
从不失败的不叫测试了吧，或许可以叫 保障？
单单强调自动化测试覆盖率，除了年终总结，没有太大的意义。
def add_one(num)
return 2
end
def test_add_one()
raise 'wrong result' unless add_one(1) == 2
end
这样代码覆盖率很高的
