难以进行单元测试的方法类型？

Question

哪些单元测试通常难以编写，为什么？我对不需要嘲笑的方法特别感兴趣。

由于

Answer 1

两个单元测试困难的案例：

调用属于其他类的静态方法的方法，特别是当其他类具有静态或执行重要工作时。陷入困境试图“单元”测试一个方法，通过传递闭包，数据库查询可以吸收。

直接创建其他类的实例的方法（即，通过new），特别是当另一个类的构造函数本身需要静态时，或者它在构造函数中执行重要工作时。

Answer 2

一个很好的A到Z可测性问题指南，可以在Misko广泛的testability guide中找到易于/难以测试代码的并排代码示例。

点击“缺陷#x”链接（它们看起来像纯文本，但它们是单独的链接）。

Answer 3

大而复杂的方法可以同时完成很多事情，而这些方法确实应该是分开的。 （例如：从配置对象中获取内容，根据某些变量创建URL，对URL进行编码，发送请求，对响应执行某些操作......您将获得演练）。

一切都是静止的。使用New创建的东西，虽然我没有找到一种正确的方法来避免它，而不会在工厂发送整个应用程序。

Answer 4

几乎总是关于依赖性。

大多数代码依赖于外部系统，例如数据库，文件系统，电子邮件客户端，网络等。在主要内部系统（例如，拼写检查模块或重新计算引擎......）上依赖于它也很常见。

如果这些依赖性不易替代，则系统变得难以测试。 调用静态和单例的类是最严重的违规者，但是任何不通过构造函数或属性接受它的依赖的类都很难测试。

有一些合法的情况难以测试：

1. 并发
2. 用户界面 - 这就是为什么趋势是创建可以轻松测试的ViewModel的MVC架构。实际渲染被最小化 - 这在测试文献中被称为简陋对话或不起眼的对象模式。