TDD和代码覆盖率

Question

我即将开始研究利用代码覆盖率进行开发，并想知道它通常是如何与测试驱动开发结合的。

代码覆盖率是事后考虑的吗？你的流程大致是这样的：

1. 编写要实现功能的测试
2. 运行测试，确保它们失败
3. 实现功能
4. 运行测试，确保它们通过
5. 为功能编写更多的测试，直到达到100%（或接近）的代码覆盖率

还是在实现了许多功能片段之后最终运行代码覆盖率，并返回并努力实现100％的覆盖率？

我能想到的第三种选择是在实施功能之前努力实现100％的覆盖率。

这些选项中哪个最常见，有什么好处呢？

- Jamie Wong

Answer 1

在达到100％代码覆盖率之前，您不需要编写测试。如果你一直遵循TDD的话，那么没有任何代码是在没有经过测试要求的情况下编写的，因此你总是应该接近于100％的覆盖率。

相反地，您需要编写测试直到所有测试通过，直到所有所需测试都已编写完毕。这意味着所有所需的代码都已被编写，因为您只有在测试要求时才会编写代码。

- John Saunders

---

是的，我最近开始使用TDD，并惊喜地发现，在为一些类编写测试和代码完成后，我们使用的代码覆盖工具报告了100％的覆盖率。我不必考虑覆盖率，只需确保我只编写了必要的代码来通过测试。如果我发现自己意外地写了太多代码，我会尝试随机注释掉其中的一些部分，如果没有测试突然失败，那么我知道我还没有编写足够的测试。 - SCFrench

Answer 2

使用TDD进行新代码开发时，应该几乎总是接近100%的覆盖率，因为您不需要编写任何不需要通过测试的代码。只有当您认为代码非常简单，不需要测试（比如C#中的自动属性）时，才会有未被特别覆盖的代码。通过重构，有时可能会引入不必要的代码块或以意外的方式更改代码，因此在这一点上，您可能希望使用覆盖率来确保您没有意外引入未经测试的代码。除此之外，我会将其用作理智检查，并定期进行覆盖分析，出于同样的原因。当您的纪律性破裂并且您忽略以TDD的方式工作时，它也可以非常有用。

- tvanfosson

Answer 3

记住，你可能会有一个测试实际上使用了被巧合覆盖的代码。你需要小心处理这个问题，特别是在开始TDD时。哦，我在这个函数中，我知道我需要添加这个小小的薄荷糖，那么为什么不再加一个呢？在你意识到之前，你就有了一堆未经测试的代码。

编写测试：失败 编写代码：通过 重构：通过

返回顶部

- Gutzofter