当我认为我的代码没有经过足够的单元测试，并且我不确定接下来要测试什么时，我使用覆盖率来帮助我决定接下来要测试什么。

如果我在一个单元测试中增加覆盖率——我知道这个单元测试有价值。

这适用于未覆盖的代码，50%覆盖或97%覆盖。

如果你已经做了相当长一段时间的单元测试，我认为没有理由不接近95%以上。然而，至少，我总是使用80%的测试，即使是刚开始测试的时候。

这个数字应该只包括在项目中编写的代码(不包括框架、插件等)，甚至可能排除完全由调用外部代码编写的代码组成的某些类。这种电话应该被嘲笑。

我最喜欢的代码覆盖率是100%。星号之所以出现，是因为我更喜欢使用工具，允许我将某些行标记为“不算数”的行。如果我已经覆盖了100%“有用”的行，我就完成了。

底层流程是:

我编写测试来测试我能想到的所有功能和边缘情况(通常从文档开始工作)。 我运行代码覆盖工具 我检查了所有没有覆盖的线或路径，以及我认为不重要或无法到达的线或路径(由于防御性编程)，我将其标记为不算数 我编写了新的测试来覆盖缺失的行，并在没有提到这些边缘情况时改进文档。

这样，如果我和我的合作者将来添加新代码或更改测试，就会有一条亮线告诉我们是否错过了重要的东西——覆盖率下降到100%以下。然而，它也提供了处理不同测试优先级的灵活性。

在我看来，答案是“这取决于你有多少时间”。我试着达到100%，但如果我没有在我拥有的时间内完成它，我也不会大惊小怪。

当我编写单元测试时，我戴着与开发产品代码时不同的帽子。我考虑测试的代码声称要做什么，以及可能破坏它的情况是什么。

我通常遵循以下标准或规则:

单元测试应该是关于我的代码的预期行为的一种文档形式。给定特定输入的预期输出以及它可能抛出的客户端可能想要捕获的异常(我的代码的用户应该知道什么?) 单元测试应该帮助我发现我可能还没有想到的假设条件。(如何使我的代码稳定和健壮?)

如果这两条规则不能产生100%的覆盖率，那就顺其自然吧。但是一旦我有时间，我就会分析未覆盖的块和行，并确定是否仍然存在没有单元测试的测试用例，或者是否需要重构代码以消除不必要的代码。

根据代码的关键程度，75%-85%是一个很好的经验法则。 运输代码肯定应该比房屋公用事业等更彻底地测试。

直到几天前，我们的目标是>的80%，但在我们使用了大量生成代码后，我们并不关心%age，而是让审核人员决定覆盖率要求。