TDD和代码覆盖率

Question

我即将开始考虑使用代码覆盖进行开发，我想知道它通常如何适合测试驱动开发。

代码覆盖是否是事后的想法？您的流程是否类似于

1. 为要实施的功能编写测试
2. 运行测试，确保它们失败
3. 实施功能
4. 运行测试，确保通过
5. 在获得100％（或接近）代码覆盖率之前，为功能编写更多测试

或者，在实施了大量功能部件之后，您是否在最后运行代码覆盖率，然后返回并实现100％覆盖率？

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

其中哪一种最常见，有哪些好处？

Answer 1

在达到100％的代码覆盖率之前，您不会编写测试。如果你一直在关注TDD，那么就会有一些 no 代码，这些代码是在没有测试要求的情况下编写的，所以你应该总是接近100％的覆盖率。

相反，您编写测试直到所有测试通过，直到所有测试都已写入。这意味着所有必需的代码都已编写，因为如果测试需要，您将只编写代码。

Answer 2

使用TDD，在开发新代码时几乎总是接近100％的覆盖率，因为您不开发任何不需要通过测试的代码。只有当您认为代码非常简单以至于您不需要测试时（比如C＃中的自动属性），您是否应该拥有未明确涵盖的代码。您可以通过重构有时引入不必要的块或以意外方式更改代码，因此您可能希望在此时使用coverage以确保您不会意外地引入未经测试的代码。除此之外，我会说我更多地使用它作为一个健全性检查，并出于同样的原因定期进行覆盖率分析。当你的学科崩溃并且你忽略了以TDD方式工作时，它也会非常有用。

Answer 3

请记住，您可以进行实际使用巧合覆盖的代码的测试。你需要注意这一点，特别是在启动TDD时。哦，我正在使用这个功能，我知道我需要添加这个小小的薄薄的晚餐薄荷，而我在为什么不是另一种薄荷。在您知道它之前，您有一堆未经测试的代码。

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

转到顶部