单元测试(unit testing)已经越来越得到广大开发者的认可。作为低成本、速度快、稳定度高的自动化测试手段，单元测试可以在类和函数级别对代码进行质量守护，有助于避免尴尬、耗时的错误。当然，相比功能测试(Functional testing)和端到端测试(end-to-end testing)，单元测试能够寄予的产品级别的信心要略低一些，因而各个粒度的测试应该是相辅相成的，互为补充。
常常听到一些组织要求开发团队提高单元测试覆盖率，换来的却是怨声载道，或者是一堆应付差事的垃圾测试（没有断言的测试，都见过吧）。尽管，低测试覆盖率意味着对质量的信心不足，但是，单元测试覆盖率真的要达到100%才好吗？
100%听起来肯定比95%要好，但是区别在于那些额外测试的价值对你可能是微不足道的。这要看哪种代码没有被测试覆盖，以及你的测试能否暴露程序的错误。100%的覆盖率并不能够确保没有缺陷——它只能保证你所有的代码都执行了，而不管程序的行为是否满足要求。与其追求代码覆盖率，不如将重点关注在确保写出有意义的测试。
测试越多，额外测试的价值越少。第一个测试最有可能是针对代码最重要的区域，因此带来高价值与高风险。当我们为几乎所有事情编写测试后，那些仍然没有测试覆盖的地方很可能是最不重要和最不可能破坏的。
编写一些测试是不费脑筋的，但随着我们接近完全的代码覆盖率，我们不那么确定了——我们差不多已经为一切都编写了测试，而剩下的没有测试的代码是微不足道，几乎不会破坏。这就是所谓的收益递减。要想从单元测试中获得更多的收益，需要重新将单元测试从质量工具定位成设计工具。TDD等方式可以帮助我们做到这一点。
换句话说，向代码基增加100个精挑细选的自动化测试是明显的改善，但当我们已有30000个测试时，这些额外的100个测试就无足轻重了。
比赛场上的赢家是那些将注意力集中在赛场上的选手，而不是紧盯着计分板的人。—巴菲特
总之，当你觉得生产环境中报来的bug很少了，或者你能够自信地对代码随时进行修改，单元测试就已经足够多了。
另一方面，也有些观点认为，不但不值得追求高覆盖率，甚至写单元测试本身就是非常耗时和难以维护的重复工作。这种极端观点我同样不赞同。
代码覆盖率不能告诉我们代码质量的高低，也不能用了评判开发人员的绩效。但它能够告诉我们哪些代码还没有被测试覆盖，哪里有漏网之鱼。至于这鱼值不值得抓，还是取决于开发人员的经验进行风险判断。那么，接下来我们再来分析一下，到底哪些鱼值得抓。
