13

无法测试的代码真的让我很恼火。以下情况使 oo-code 无法测试：

  • 全局状态，例如单例设计模式
  • 做一些花哨的工作的静态方法，例如数据库访问
  • 深层继承树
  • 在构造函数中工作，例如控制语句
  • 违反单一职责原则的类

是否有更多警告信号？

4

10 回答 10

13

这些都不会使代码无法测试。它们可能会使发现边缘案例错误变得更加困难，但是，如果您已经完全指定了测试的成功标准（并且测试驱动的开发简化了这一点），您所要做的就是通过标准。

TDD 可以应用于特定部分以及整个项目的行为，因此您可以轻松测试非常小的组件。但是，它的目的是测试结果，而不是获得这些结果的方法。

如果测试通过，则您已满足要求。如果之后有错误，这是测试的问题，而不是正在测试的代码（在这种情况下，应该修改测试以捕获以前无法预料的问题）。

您不应该关心（就功能的交付而言）您的一个构造函数中是否有 while 语句。您应该问自己什么业务需求要求这样做？我强烈怀疑您的客户会提供一份要求清单，包括“继承限制为 4 个级别”。他们很可能将“无错误”列为一项要求，但您必须就此进行协商:-)。

于 2009-01-05T08:07:09.787 回答
13

请参阅 Miško Hevery 的以下博客文章：如何编写 3v1L，不可测试的代码。

于 2009-01-05T08:11:04.177 回答
7

硬编码的依赖项。

于 2009-01-05T07:48:30.823 回答
5
  • 不对接口编程
  • 更新对象而不是使用工厂/IOC
于 2009-01-05T08:04:03.537 回答
2

在与演示无关的 GUI 类中完成的工作。GUI 应该与底层模型完全解耦。

于 2009-01-05T08:55:34.743 回答
1

只要您不能修改代码，代码就无法测试。如果您有可能重构项目，那么没有代码是不可测试的。通常，只需要很小的修改就可以使测试更容易。而且它们是合理的，因为它们提高了代码的质量。

即使在您描述的情况下，代码也不一定是不可测试的。只是更难测试。例如，如果您可以隔离数据库访问并在单元测试期间避免它们，那么测试代码会更容易。但如果必须，您可以建立一个专门用于运行测试的数据库。

于 2009-01-05T09:14:15.360 回答
1

我会说这些都不会使代码无法测试。它们确实使单元测试变得困难，因为每一个都增加了实现中的耦合。

在其他使单元测试变得困难的烦恼中：

通常，您可能听到的有关创建更好代码的任何建议也是更易于单元测试代码的建议。

于 2009-01-05T09:14:46.170 回答
1

数据库！特别是那些有触发器的！

我知道你可以模拟数据库，但我一直发现我的代码（主要是 CRUD 应用程序）中的大多数错误都是数据/映射问题，如果你模拟数据库，你不会发现那种错误。

于 2009-01-05T09:53:14.127 回答
1

Miško Hevery 的编写可测试代码指南详细介绍了使代码难以测试的缺陷。他的清单与您的清单有些重叠，但细节令人难以置信。

  • 构造函数做真正的工作
  • 挖掘合作者
  • 脆弱的全球状态和单身人士
  • 课堂做得太多
于 2009-01-05T16:17:10.843 回答
0

缺乏分层，过度耦合... 即类 Y 已被编写为了解 X，但它不应该，X 是可重用的。可测试性和可重用性之间有很强的关系。

于 2009-01-05T09:23:57.587 回答