测试代码覆盖工具的价值

Question

我们已经开始使用零件封面来跟踪我们应用程序的测试代码覆盖范围。海事组织是一个很好的工具，可以为您的测试获得总分，并突出显示您可能对测试有点懒惰的测试领域，但今天我写了一个测试，并意识到它没有真正测试任何有用的东西，它只是增加了我的报道！

如果您是TDD，那么您只需编写代码来通过测试，并且测试可以丰富地描述应用程序所需的所有功能。那么在这种情况下，覆盖分析仍然非常有价值吗？

对于那些有覆盖率的工具，你坚持如何保持100％的覆盖率，你是否发现自己编写的测试不是真的测试任何东西，只是为了保持你的覆盖面？这不是一个坏事？

Answer 1

覆盖工具只能用于告诉您什么不是已经过测试。你指出的场景说明了为什么你不能依靠它们向你展示哪些代码已经过测试。如果覆盖率为100％，编写测试是毫无意义的（正如您所怀疑的那样），并且游戏非常简单，这并不是一个真正有用的指标。我曾经尝试并保持在100％或接近100％，但我得出的结论与你所做的一样。我正在写测试，没有真正测试任何东西，所以数字是正确的。使用这些工具来确定尚未测试的区域，然后编写好的测试或接受这些代码部分不重要的事实。

Answer 2

良好的理性化;）但我们毕竟是人类，我知道一个未经测试的方法或路径并没有投入生产，所以在夜间睡得更好。

Answer 3

如果你在做纯粹的TDD，那么代码覆盖的价值就会降低，因为正如你所说，你只能从测试中编写代码，所以你应该在100％左右。但是，这可能是非常罕见的（有时不可能）纯粹如此。

如果你不是纯粹的TDD，100％是一个非常不切实际的目标。我通常会尝试着选择Roy Osherove的方法，只用逻辑来测试（比如不是直接的getter/setter或pass-through）。但是，越高越好，并且可以在这里增加更多测试以增加覆盖率。

Answer 4

我会扮演魔鬼的拥护者：如果增加你的覆盖面意味着写一个测试“没有测试任何有用的东西”，那么为什么那里的代码？对我来说，这将是一个删除一些主线代码的参数。

或者开发一个确实有用的测试。例如，你可能会认为它对测试设置者和获取者没有用处。我也没有。但是，这些方法应测试，而测试别的东西。否则，再次，他们为什么在那里？

但你提出一个好的观点，即覆盖工具本身不应该是目的。特别是因为他们不能告诉你你需要写什么代码。

我已经在这里更详细了：http://www.kdgregory.com/index.php?page=junit.coverage