VIP Data

此方法违反了迪米特法则，因为它需要遍历对象图来获取完成其工作所需的信息。将不必要的信息传递到类和方法中会损害可测试性。

想象一个巨大的 BillingContext 对象，其中包含对其他对象的引用：


我们可以看到，我们的测试充斥着不必要的信息。创建复 巴拿马电报号码数据 杂对象图的测试难以阅读，并引入了不必要的复杂性。



您应该始终将直接依赖项传递到类和方法中。但是，将许多参数传递到方法中也不是一个好习惯 - 理想情况下，您应该最多传递两个参数或将密切相关的参数包装到数据对象中。

上帝物体
上帝对象是指引用许多其他不同对象的对象，具有不止一个职责，并且有多个改变原因。如果很难总结出该类的作用，或者总结中包含“和”这个词，则该类很可能具有不止一个职责。



上帝对象很难测试，因为我们要处理多个不相关的依赖项，混合各种抽象和关注点，并且它们会产生很多副作用。因此，很难达到我们测试用例的预期状态。

例如：


UserService 有多项职责——注册新用户和发送电子邮件。在测试用户注册时，我们需要处理电子邮件服务，反之亦然：


想象一下，一个 UserService 有两个以上不相关的依赖项。这些依赖项又有自己的依赖项，依此类推。我们最终会得到一个不可读的测试，它充斥着不相关的信息，而且很难理解。因此，每个类都应该只有一个职责和更改理由。只有一个更改理由的类是五项软件设计原则之一，称为单一职责原则。

您可以在此处阅读有关 SOLID 原则的更多信息。

结论
遵循软件设计最佳实践的代码库使编写单元测试变得更加容易。

另一方面，使用上述反模式为代码库编写工作单元测试可能非常具有挑战性，有时甚至是不可能的。编写良好的可测试代码需要大量的练习、纪律和额外的努力。可测试代码的最大优势是易于测试以及理解、维护和扩展该代码的能力。

我们希望本博客能帮助您编写可测试代码！