好测试，坏测试
事实上写出好的测试和写出好的生产代码一样难，需要精心练习和深思熟虑。然而我太多次看到测试代码被当作二等公民。这种情况往往意味着我们没有从测试中得到应有的益处，到头来测试集更像个累赘而非资产。好的测试集：1. 带来信心2. 能抓到bug3. 易于打理4. 描述系统5. 结实6. 自己没有bug7. 在运行信心当修改代码后，运行了测试就足以放心提交代码么？直接上线呢？
我的经验是单元测试是不够的，我们需要一些全栈测试，BDD以及集成测试来增加信心。需要注意的是对于同一个功能点如果有两个测试给你信心，那么有一个测试是多余的。另外，如果你真的对测试集很有信心，但是你发布的产品中bug仍然持续增加，你的信心可能放错了地方。抓到bug如果你有个永远不会红灯的测试，它毫无价值因为它不会抓住任何bug，而这是测试存在的主要原因。易于打理如果你在重构代码的时候花了大量的时间修改测试或者重写测试，你的测试集就没有值回票价。如果你使用了大量的mock对象的话，我发现更是如此。很多情况下最终得到的是过分规格化的软件。描述系统测试用例应该告诉我们系统做了什么，最好还能告诉我们为什么做这些事。
只有很少的测试应该用来告诉我们它是怎么做的，而且我们知道如果进行大的重构时会扔掉这些测试。本身没有bug知道测试确实在测它的目标代码，也就是说测试本身没有bug的最好办法，就是在改了生产代码后，看着测试从红灯变为绿灯。这就是为什么应该在写生产代码之前写测试。另外考虑使用变异测试来找到测试集的盲点。结实如果你的测试集里有个反复无常的测试，莫名其妙的失败。它将危害整个测试集因为大家将不再把测试失败当回事。
删掉这种测试。被人运行也许这听起来有点傻，但是我确实看到过也写过很多测试却没人去跑。包括：· 被注释掉的或打上@Ignored标签的测试。· 非常慢的测试。· 需要一些手工步骤的测试，比如安装数据库，应用程序容器或者消息中间件。· 无法从IDE运行或者调试的测试。
总而言之，好的测试集将会支撑我们对系统进行演进。
测试应该支持改变，而非阻碍改变。
毕竟，正如Dave Thomas 和 Andy Hunt 所言，我们总是在改变现有系统。所有的编程都是维护性的工作，因为我们极少写全新的代码。
只有在你刚刚敲进去那10分钟里代码是全新的。
重要通知：博为峰网校助力求职季，特别推出测试集训营，更多自动化测试好课打折、送券……惊喜不停歇，快来~活动链接：http://h.atstudy.com/activity/
页:
[1]
