我对这个难题的回答是，对可以测试的代码有100%的行覆盖率，对不能测试的代码有0%的行覆盖率。

我目前在Python中的做法是将.py模块分为两个文件夹:app1/和app2/，当运行单元测试时，计算这两个文件夹的覆盖率，并直观地检查(有朝一日我必须自动化)app1的覆盖率为100%，而app2的覆盖率为0%。

当/如果我发现这些数字与标准不同，我会调查并改变代码的设计，使覆盖率符合标准。

这意味着我可以建议实现库代码的100%行覆盖率。

我也偶尔检查app2/，看看我是否可以在那里测试任何代码，如果我可以，我将它移动到app1/

现在我不太担心总覆盖率，因为这取决于项目的规模，但通常情况下我看到的是70%到90%以上。

使用python，我应该能够设计一个烟雾测试，可以自动运行我的应用程序，同时测量覆盖率，并有希望获得100%的烟雾测试与单元测试数字的聚合。

代码覆盖率只是另一个度量。就其本身而言，它可能非常具有误导性(参见www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated)。因此，您的目标不应该是实现100%的代码覆盖率，而是要确保您测试了应用程序的所有相关场景。

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

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

底层流程是:

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

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

如果你的目标是100%的覆盖率(而不是100%测试所有功能)，那么代码覆盖率就是一个误导的指标。

你可以通过一次命中所有的线来获得100%。然而，您仍然可能错过测试这些行命中的特定序列(逻辑路径)。 您不能得到100%，但仍然测试了所有80%/频率使用的代码路径。测试每个“抛出ExceptionTypeX”或类似的防御性编程保护是“有就好”而不是“必须”

所以要相信你自己或你的开发人员是彻底的，并覆盖他们代码中的每一条路径。要务实，不要追求神奇的100%覆盖率。如果你用TDD开发你的代码，你应该得到90%以上的覆盖率作为奖励。使用代码覆盖来突出你错过的代码块(如果你使用TDD就不应该发生这种情况。因为您编写代码只是为了通过测试。没有伙伴测试，任何代码都不能存在。)

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

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

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