【译文】好测试，坏测试

本文转自 GitChat 作者 武可 在简书上的翻译文章

原文地址：http://www.jianshu.com/p/da63b06a0ed0

翻译自：http://danlebrero.com/2016/11/06/good-test-vs-bad-tests/

单元测试,正如其它实践一样，有收益也有代价。你怎么知道你的测试集是物有所值的呢？

单元测试，就像任何实践一样，可能被滥用。我写过一篇关于这个话题的文章（http://www.jianshu.com/p/34a55517bcc1）。

事实上写出好的测试和写出好的生产代码一样难，需要精心练习和深思熟虑。然而我太多次看到测试代码被当作二等公民。这种情况往往意味着我们没有从测试中得到应有的益处，到头来测试集更像个累赘而非资产。

好的测试集：

带来信心

能抓到bug

易于打理

描述系统

结实

自己没有bug

在运行

信心

当修改代码后，运行了测试就足以放心提交代码么？直接上线呢？
我的经验是单元测试是不够的，我们需要一些 全栈测试（http://martinfowler.com/bliki/BroadStackTest.html），BDD 以及集成测试来增加信心。

需要注意的是对于同一个功能点如果有两个测试给你信心，那么有一个测试是多余的。

另外，如果你真的对测试集很有信心，但是你发布的产品中 bug 仍然持续增加，你的信心可能放错了地方。

抓到 bug

如果你有个永远不会红灯的测试，它毫无价值因为它不会抓住任何 bug，而这是测试存在的主要原因。

易于打理

如果你在重构代码的时候花了大量的时间修改测试或者重写测试，你的测试集就没有值回票价。如果你使用了大量的 mock 对象的话，我发现更是如此。很多情况下最终得到的是过分 规格化的软件（http://xunitpatterns.com/Fragile%20Test.html#Overspecified%20Software）。

描述系统

测试用例应该告诉我们系统做了什么，最好还能告诉我们为什么做这些事。
只有很少的测试应该用来告诉我们它是怎么做的，而且我们知道如果进行大的重构时会扔掉这些测试。

本身没有bug

知道测试确实在测它的目标代码，也就是说测试本身没有 bug 的最好办法，就是在改了生产代码后，看着测试从红灯变为绿灯。

这就是为什么应该在写生产代码之前写测试。

另外考虑使用变异测试（http://pitest.org/）来找到测试集的盲点。

结实

如果你的测试集里有个反复无常的测试，莫名其妙的失败。它将危害整个测试集因为大家将不再把测试失败当回事。
删掉这种测试。

被人运行

也许这听起来有点傻，但是我确实看到过也写过很多测试却没人去跑。包括：

被注释掉的或打上 @Ignored 标签的测试。

非常慢的测试。

需要一些手工步骤的测试，比如安装数据库，应用程序容器或者消息中间件。

无法从 IDE 运行或者调试的测试。

总而言之，好的测试集将会支撑我们对系统进行演进。
测试应该支持改变，而非阻碍改变。

毕竟，正如 Dave Thomas 和 Andy Hunt 所言（http://www.artima.com/intv/dry.html），我们总是在改变现有系统。

所有的编程都是维护性的工作，因为我们极少写全新的代码。 只有在你刚刚敲进去那10分钟里代码是全新的。

微信搜一搜【程序员一凡】关注这个文绉绉的程序员，关注后回复【面试】有我准备的一线大厂面试资料和简历模板，希望大家都能找到心仪的工作，学习是一条时而郁郁寡欢，时而开怀大笑的路，加油。如果你通过努力成功进入到了心仪的公司，一定不要懈怠放松，职场成长和新技术学习一样，不进则退。如果有幸我们江湖再见！

如果对软件测试、接口、自动化、性能测试、测试开发、面试经验交流。感兴趣可以1079636098，群内会有不定期的发放免费的资料链接，这些资料都是从各个技术网站搜集、整理出来的，如果你有好的学习资料可以私聊发我，我会注明出处之后分享给大家。