业务应用的单元测试覆盖率可以低一些，框架和工具箱的覆盖率必须要很高
单元测试的覆盖率高当然很好，但高的覆盖率意味着要写很多测试；而写测试本身是件费脑费时的事情，代价不低。 所以要在收益和代价之间取得平衡。
可以着眼现在，放眼未来，具体考量四个因素：
1. 对代码正确性的要求。 要求越高，覆盖率就应该越高。
2. 能否人肉测试。 如果用人肉可以做测试，则自动化运行的单元测试代码可以少一些
3. 代码逻辑的易变性。 代码逻辑越易变，写的测试被浪费的概率越大，对低覆盖率的容忍度越大
4. 发现bug时的易改性。 出现bug的代码越容易改，对低质量的容忍度越大，对低覆盖率的容忍度也越大
以互联网为例，在业务应用层面，可以为了迅速推出新产品而容忍一定的bug，可以用鼠标进行人肉测试，产品易变代码逻辑也易变，发现bug时也容易改，所以这一块的测试覆盖率可以低一些
而框架、工具箱等Module的代码正确性必须非常高，否则会影响很多上层模块和系统；没有界面因此不能人肉测试； 代码逻辑不怎么变，单元测试被浪费的概率不高；一旦出现bug，受牵连的上层模块和系统可能会非常多，因此不能轻易让bug出现。 所以，框架、工具箱等Module的测试覆盖率必须非常高。