|
|
1
18
如果您模拟事件和事件聚合器,并使用moq的回调,那么您可以这样做。 下面是一个例子:
|
|
|
2
15
我真的认为你应该对所有东西使用mock,而不是eventaggregator。嘲笑一点都不难…我认为链接的答案并不能证明eventaggregator的可测试性。 这是你的测试。我不使用mspec,但这里是moq的测试。你没有提供任何代码,所以我基于链接到的代码。您的场景比链接的场景稍微难一点,因为另一个操作只是想知道如何验证正在调用subscribe,但是您实际上想调用在subscribe中传递的方法……更困难的事,但不是很难。
|
|
|
3
5
你可能不喜欢这个,因为它可能涉及到你认为是“丑陋的黑客”,但我的偏好是使用一个真正的事件聚合器,而不是嘲笑一切。虽然表面上是一个外部资源,但eventaggregator运行在内存中,因此不需要太多设置、清除,而且不像其他外部资源(如数据库、web服务等)那样是一个瓶颈,因此我觉得在单元测试中使用它是合适的。在此基础上,我使用此方法克服了nunit中的ui线程问题,并且为了测试,对我的生产代码进行了最小的更改或风险。 首先我创建了一个扩展方法,如下所示:
} 然后,在我的所有事件订阅中,我使用以下内容:
在生产代码中,这只是无缝工作。出于测试目的,我所要做的就是在设置中添加此项,并在测试中添加一点同步代码:
为了使等待和脉冲更加简洁,我还向threadingextensions添加了以下扩展方法:
然后我可以:
再说一次,如果你的感性意味着你想用嘲笑,那就去做吧。如果你愿意用真品,这是可行的。 |