代码覆盖率是很好的，但前提是你从中得到的好处超过了实现它的成本/努力。

一段时间以来，我们一直在努力达到80%的标准，但我们刚刚决定放弃这个标准，转而更专注于我们的测试。专注于复杂的业务逻辑等，

这个决定是由于我们花在追逐代码覆盖率和维护现有单元测试上的时间越来越多。我们觉得我们已经到达了这样一个点:我们从代码覆盖率中得到的好处被认为比我们为实现它所付出的努力要少。

看看Crap4j。这是一种比直接代码覆盖稍微复杂一些的方法。它结合了代码覆盖率度量和复杂性度量，然后向您展示哪些复杂的代码目前没有测试。

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

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

底层流程是:

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

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

如果这是一个完美的世界，100%的代码将被单元测试覆盖。然而，因为这不是一个完美的世界，这是一个你有时间做什么的问题。因此，我建议少关注特定的百分比，而更多地关注关键领域。如果你的代码写得很好(或者至少是一个合理的副本)，应该有几个关键点将api暴露给其他代码。

将您的测试工作集中在这些api上。确保api是1)良好的文档化的，2)已经编写了与文档相匹配的测试用例。如果预期的结果与文档不匹配，那么您的代码、文档或测试用例中都存在bug。所有这些都是值得调查的。

好运！

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

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

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

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

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