我们已经开始使用 Part Cover 来跟踪我们应用程序的测试代码覆盖率。 IMO 它是一个很好的工具，可以为您的测试获得总体分数并突出显示您可能对测试有点懒惰的测试区域，但今天我写了一个测试并意识到它并没有真正测试任何有用的东西，它只是增加了我的报道！
如果您是 TDD，那么您只需编写代码以通过测试，并且测试丰富地描述了应用程序所需的所有功能。那么在这种情况下，进行覆盖率分析是否仍然非常有价值？
对于那些拥有覆盖率工具的人，你是如何虔诚地坚持将覆盖率保持在 100% 的，你是否发现自己编写的测试真正测试任何东西，而只是为了保持你的覆盖率？这不是坏事吗？
【问题讨论】：
标签： testing tdd code-coverage
覆盖工具应该只用于告诉您没有测试过的内容。您指出的场景说明了为什么您不能依赖它们来向您展示已测试的代码。仅仅为了 100% 的覆盖率而编写测试是没有意义的（正如你所怀疑的那样），而且它很容易玩，以至于这并不是一个真正有用的指标。我曾经尝试保持在 100% 或接近 100%，但我得出了与您相同的结论。我正在编写的测试并没有真正测试任何东西，所以数字是正确的。使用工具找出您尚未测试的区域，然后编写好的测试或接受这些代码部分并不重要的事实。
【讨论】：
我将扮演魔鬼的拥护者：如果增加您的覆盖率意味着编写一个“没有测试任何有用的东西”的测试，那么为什么会有这段代码呢？对我来说，这将是删除一些主线代码的论据。
或者开发一个做一些有用的测试。例如，您可能认为测试 setter 和 getter 没有用。我也没有。但是，应该在测试其他方法的同时测试这些方法。否则，他们又为什么会在那里？
但是您提出了一个很好的观点，即覆盖工具本身不应该是目的。特别是因为他们无法告诉您需要编写什么代码。
我在这里更详细地介绍了：http://www.kdgregory.com/index.php?page=junit.coverage
【讨论】：
如果您正在执行纯 TDD，那么代码覆盖率的价值就会降低，因为正如您所说，您只从测试中编写代码，所以无论如何您应该在 100% 左右。但是，如此纯粹地这样做可能非常罕见（有时是不可能的）。
如果您不进行纯 TDD，那么 100% 无论如何都是一个非常不切实际的目标。我通常尝试采用 Roy Osherove 的方法，并且只用逻辑测试事物（例如，不是直接的 getter/setter 或 pass-throughs）。但是，更高总是更好，并且可能很容易在其中进行更多测试以增加覆盖率..！
【讨论】：
很好的合理化 ;) 但我们毕竟是人类，而且我知道未经测试的方法或路径尚未投入生产，因此我晚上睡得更好。
【讨论】：