单元测试 – 如何避免从嘲笑的对象列表中返回嘲笑

我正在尝试模拟/责任驱动的设计.在需要服务来检索其他对象的对象的情况下,我似乎有一些问题要避免从mock返回mocks.

一个例子可以是检查上个月的帐单是否支付的对象.它需要一个检索帐单列表的服务.所以我需要在我的测试中嘲笑这个billRetrievalService.同时我需要BillRetrievalMock来回复嘲笑的条例草案(因为我不希望我的考试依靠Bill的实施).

我的设计有缺陷吗?有更好的方法来测试吗?或者这是在使用finder对象(在这种情况下发现账单)时需要的方式?

旁注:althout Bill可能是一个值对象候选者,当集合不包含值对象(例如Users)时,更广泛的问题仍然存在.

大多数情况下,如果我需要一个模拟来返回另一个模拟,我会发现一个依赖关系在另一个方面更有意义.换句话说,模拟回归模拟通常指的是违反依赖性反转原则.

一个常见的例外:创建对象的工厂(而不是每次只返回相同对象的“持有者”).如果我需要在我的生命周期中创建相同类型的多个对象,那么我可能需要依赖于一个ObjectFactory并调用#createObject(),然后可能对对象设置期望值.即使如此,我也会质疑.调用堆栈中的其他东西可能有可能为我创建对象,并根据需要给予我们.

在ObjectHolder的情况下,而不是依赖于ObjectHolder来获取Object,我更喜欢直接依赖Object,并强制我的调用者给它但是它想要的.这尊重了上下文独立性的理想设计特性.

这个问题的一个特定版本是“虚拟时钟”模式.有时您需要依赖于虚拟时钟,但通常更需要时间戳. (“即时请求”模式)

相关文章

迭代器模式(Iterator)迭代器模式(Iterator)[Cursor]意图...
高性能IO模型浅析服务器端编程经常需要构造高性能的IO模型,...
策略模式(Strategy)策略模式(Strategy)[Policy]意图:定...
访问者模式(Visitor)访问者模式(Visitor)意图:表示一个...
命令模式(Command)命令模式(Command)[Action/Transactio...
生成器模式(Builder)生成器模式(Builder)意图:将一个对...