C# 代码覆盖工具和TDD

我最近一直在评估JetBrains的DotCover，这让我想到了一个有趣的问题

当遵循TDD时：

• 我将针对我想要的理想接口编写一个测试
• 红色的
• 创建最简单的实现以通过测试
• 绿色的
• 运行DotCover，它显示100%
• 然后我将删除复制/重构

如果在重构过程中，我将一些功能移到它自己的类中（比如为了坚持DRY或SRP），然后重新运行DotCover，那么覆盖率%将随之下降，因为我不再直接测试新类

这对我来说似乎有点奇怪，因为我完全遵循TDD的原则。如果我修改或注释掉代码中的任何一行，测试将中断，但报告为未覆盖

---

我遗漏了什么吗？

Dotcolve可能希望您的单元作为单元进行测试，因此间接测试将受到惩罚。而且，只有被测试的系统才应该在测试中被考虑的观点也有一些优点；当您提取一个类，但通过调用者对其进行测试时，您实际上是在测试调用者，并且应该（可以说）模拟新类，并对新类进行真正的单元测试，将其作为一个独立的单元进行测试。

我想这开启了单元测试与集成测试定义的争论

您可以使用过滤器从代码覆盖范围中排除区域：

---

希望这有帮助

如果您将该逻辑移动到新类，那么新类应该已经被覆盖，因为您从中获取它的代码现在正在调用它。我不熟悉DotCover，但我使用过Visual Studio one，它的覆盖率仅基于代码是否执行，而不是单元测试是如何编写的。嗯？为什么要投反对票？测试正在执行有问题的代码，但显示为未涵盖。我会尝试另一种测试工具。如果你是TDD，我不会专注于代码覆盖率。我只在完成一个功能后才查看覆盖率。您是否运行了覆盖范围内的所有测试，因为只运行一个测试可能会产生奇怪的结果。这是我关心的问题。如果这些不同的单元可能被不同的消费者使用，我可以理解将单元作为彼此完全解耦的单元进行测试的优点。但是，如果这些单元被标记为内部单元，并且所有代码都由当前测试执行，那么我认为额外的测试将只是维护负担。我认为将修饰符更改为public不会破坏任何测试，并且会向其他消费者公开这些测试。你对这两种方法的优缺点有什么想法吗？很抱歉，我对.net的了解还不够透彻，无法给出一个好的答案。一个真正只对另一个类有用的类应该是另一个类的内部和私有类，我不想为了测试而将它公开。@CarlManaster我同意你的观点，这也取决于你如何定义一个单元，对我来说，一个单元就是一个或多个类。我的一些同事不同意这一点，他们会让每一个类都单独测试，我认为这是浪费和愚蠢的，并且会导致通常需要更多的嘲弄/存根。