好测试，坏测试

学掌门网校

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

好的测试集：

1. 带来信心

2. 能抓到bug

3. 易于打理

4. 描述系统

5. 结实

6. 自己没有bug

7. 在运行

信心

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

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

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

抓到bug

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

易于打理

如果你在重构代码的时候花了大量的时间修改测试或者重写测试，你的测试集就没有值回票价。如果你使用了大量的mock对象的话，我发现更是如此。很多情况下最终得到的是过分规格化的软件。

描述系统

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

本身没有bug

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

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

另外考虑使用变异测试来找到测试集的盲点。

结实

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

被人运行

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

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

· 非常慢的测试。

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

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

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

毕竟，正如Dave Thomas 和 Andy Hunt 所言，我们总是在改变现有系统。

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

重要通知：

博为峰网校助力求职季，特别推出测试集训营，更多自动化测试好课打折、送券……惊喜不停歇，快来~

活动链接：http://h.atstudy.com/activity/