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