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

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

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

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

85%是签入标准的一个很好的起点。

我可能会选择各种更高的发布标准——这取决于正在测试的子系统/组件的临界性。

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

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

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

代码覆盖率很好，但功能覆盖率更好。我不喜欢把我写的每一行都写一遍。但是我相信编写100%的测试覆盖我想要提供的所有功能(即使是我自己带来的额外的很酷的功能，这些功能在会议中没有讨论)。

我不关心我的代码是否会在测试中被覆盖，但我关心的是我是否会重构我的代码并最终具有不同的行为。因此，100%的功能覆盖率是我的唯一目标。

我认为不可能有这样的B/W规则。 应该审查代码，特别注意关键细节。 然而，如果它没有经过测试，它就有一个bug!