使用 Rhino Mocks 模拟输出参数,该参数是在我正在测试的方法中创建的
尝试模拟以下方法:
bool IsLoginValid(LoginViewModel viewModel, out User user);
最初尝试过这个:
dependency<ILoginService>()
.Stub(serv =>
serv.IsLoginValid(
Arg<LoginViewModel>.Is.Equal(a_login_viewmodel),
out Arg<User>.Is.Anything)
.Return(false);
但是失败了,因为它是一个输出参数。做了一些搜索并像这样改变了我的代码:
dependency<ILoginService>()
.Stub(serv =>
serv.IsLoginValid(
Arg<LoginViewModel>.Is.Equal(a_login_viewmodel),
out Arg<User>.Out(new User()).Dummy))
.Return(false);
这也失败了。我需要“new User()”作为“任何”参数。我认为这是期待一个特定的实例。
知道如何解决这个问题吗?谢谢你们。
Trying to mock the following method:
bool IsLoginValid(LoginViewModel viewModel, out User user);
Tried this initially:
dependency<ILoginService>()
.Stub(serv =>
serv.IsLoginValid(
Arg<LoginViewModel>.Is.Equal(a_login_viewmodel),
out Arg<User>.Is.Anything)
.Return(false);
But, that fails, as it is an out parameter. Did a bit of searching around and altered my code like such:
dependency<ILoginService>()
.Stub(serv =>
serv.IsLoginValid(
Arg<LoginViewModel>.Is.Equal(a_login_viewmodel),
out Arg<User>.Out(new User()).Dummy))
.Return(false);
That also fails. I need 'new User()' to be sort of an 'Anything' argument. As I think that is expecting a specific instance.
Any idea how to get around this? Thanks guys.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
尝试“OutRef”选项。它接受一个 params object[] 来定义每个输出参数的结果。由于您只有一个,因此您只需要一个结果。这是我尝试过的快速模型,应该适用于您的情况:
Try the "OutRef" option. It accepts a params object[] that defines the result for each out parameter. Since you've only got one, you only need one result. Here's a quick mock-up of what I tried that should work in your situation:
更改接受的答案(@Patrick Steele)以匹配问题中的变量名称和空格:
...然后将语法(但不是语义)更改为流畅的
Args
语法:...然后我们最终得到与OP第二次尝试完全相同的语法,这显然“失败”了。就我个人而言,我更喜欢流畅的“Args”风格,尽管它稍微冗长一些。
TL;DR OP 的第二次尝试在语义上等同于已接受的答案,只是使用了不同的语法。
Changing the accepted answer (by @Patrick Steele) to match the variable names and whitespace in the question:
...then changing the syntax (but not the semantics) to the fluent
Args
syntax:...then we end up with exact same syntax as the OP's second attempt, which apparently "fails". Personally, I prefer the fluent 'Args' style, even though it is slightly more verbose.
TL;DR the OP's second attempt is semantically equivalent to the accepted answer, merely uses a different syntax.