补测试是个无底洞，因为一直在开发新功能。就好比今天吃昨天的剩饭，明天吃今天的剩饭......
因为之前的代码在编写时没有考虑可测试性，没有合理抽象和分离关注点，导致后期添加单元测试的成本较高。
在已经手工测试过证明没有问题的代码上添加单元测试，也让人有画蛇添足的感觉。
并且按照以前的习惯，在需求变更或修复 Bug 后会进行手动测试，现在还要修改单元测试代码，更会造成一种「单元测试维护成本很高」的误解。
如果能保证新增的代码都有测试覆盖，整体测试覆盖率就会持续上升。
利用 TDD（测试驱动开发）的方式，在开发新功能，修复 Bug，做需求变更前，先新增或修改单元测试，再修改实现代码，单元测试通过即代表工作完成，减少了大量的手工测试和 Debug 时间，在完善的单元测试覆盖下还可以进行大胆重构，这样将极大提高开发效率和代码质量。
