单元测试和太多嘲笑

Question

我开始在我的项目中练习TDD,作为背景,它还包含遗留代码.我们使用Mockito作为模拟框架并遵循Spring MVC方法.

有些时候,有一个Service类使用许多不同的DAO对象作为@Autowired属性实现.这些服务中有简单的方法,例如completeTransaction.

completeTransaction将使用许多DAO对象来完成其职责

• 更新并保存交易
• 推进业务流程
• 关闭其他待处理操作

但是,在执行这些操作时,该方法需要调用不同的方法DAO来获取和更新事务,获取业务流程ID,获取挂起的事务(并保存其更新).这意味着测试此方法的单元使我添加了许多@Mock属性.我需要在测试实际完成之前设置模拟对象以测试某个条件.

这看起来像代码味道,对我而言,几乎感觉测试是确保代码的实现而不仅仅是合同.同样,在不模仿依赖关系的情况下,测试用例将不会运行(由于NPE和其他因素).

我可以遵循什么策略来清理这样的代码？(虽然我无法真正提供问题的实际源代码).我认为一种可能性是使用类似("getPendingOperations"和"advanceBusinessProcess")的方法设置外观类.然后我可以模拟一个依赖.但后来我认为在所有其他具有这种情况的类中我需要做同样的事情,然后我害怕为了更清洁的测试而最终得到很多"辅助"类.

先谢谢你.

Answer 1

我认为当你发现自己有太多的模拟时，你通常会想做两件事。这些不一定很容易，但您可能会发现它们很有帮助。

1）尝试让你的方法和类更小。我认为《清洁代码》说有两条规则，即类应该很小。而且班级规模应该比这个小。这是有道理的，因为随着您正在测试的单元（方法和类）变小，依赖项也会变小。当然，您最终会进行更多测试，但每个测试中的设置会更少。

2）看看德米特定律（https://en.wikipedia.org/wiki/Law_of_Demeter）。有很多规则，但基本上，您希望避免长字符串属性/方法调用。 objA = objB.propertyA.SomeMethod().propertyC; 如果您需要模拟所有这些对象只是为了获取 objA，那么您将需要进行大量设置。但如果你可以用它来替换它，objA = objB.newProperty;那么你只需要模拟 objB 并且它是一个属性。

这些都不是灵丹妙药，但希望您可以在您的项目中使用其中一些想法。