众所周知，DTO没有方法。
由于控制器使用DTO对象，因此存在依赖关系。我们应该在测试控制器的同时设置对DTO（模拟DTO属性）属性的期望吗？
感谢
答案 0 :(得分：4)
如果DTO只是持有价值观，那么嘲笑它就没有意义了。应该使用模拟对象来确认对象如何与其邻居协作。如果没有真正的行为，如果DTO没有提供服务，那么不要使用模拟。
答案 1 :(得分：1)
DTO是如此轻量级，以至于剔除它的额外成本似乎很愚蠢。此外，您现在需要一个DTO界面，或者必须将所有内容标记为虚拟......
答案 2 :(得分：0)
你能说出至少一件事的原因吗？
我不能。
P.S。我的意思是 - 为什么不使用属性。你的帖子中有2个有争议的问题。
答案 3 :(得分：0)
我同意Arnis L.您在测试期间将DTO传递给您的控制器（使用您需要的值初始化）并且您的DTO中没有任何东西可以测试（除非您的getter / setter中有一些逻辑，但它不是对DTO来说真是个好习惯。
答案 4 :(得分：0)
你是否正在考虑进入行动的dto或出现的行动？
进入的那个将直接用于存储库，服务或其他协作者。我会嘲笑那些并将我的期望放在那里。
您的测试代码也可以完全控制创建输入dto。
如果您想使用传出dto，我只需从ViewResult中获取该传真，并验证它是预期的。你如何做到这一点取决于你：你可以模拟存储库或与你选择的持久存储器对话。
答案 5 :(得分：0)
不要嘲笑你的DTO。创建你的DTO比创建模拟更简单，在某些情况下如果改变状态会让你遇到麻烦。
我在下面的链接中写过一个这样的经历。 Don't Mock DTOs