如果你(或你的组织)渴望彻底单元测试你的代码，你如何衡量你的努力的成功或质量？
>你使用代码覆盖率，你的目标百分比是多少？
>你发现像TDD这样的哲学比度量有更好的影响吗？
我的提示不是一个方法来确定你是否有良好的单元测试本身，但它是一种方式来成长一个好的测试套件随着时间的推移。
每当你遇到一个bug，无论是在你的开发或由别人报告，修复它两次。您首先创建一个单元测试来再现问题。当你有一个失败的测试，然后你去解决这个问题。
如果一个问题在那里首先是一个关于代码或域的一个微妙的暗示。为它添加一个测试，让你确保它永远不会被重新引入未来。
这个方法的另一个有趣的方面是，它将帮助你从更高的层次了解问题，然后你实际去看看代码的复杂性。
此外，1为其他人已经提到的测试覆盖的价值和陷阱。
