模拟控制器测试的具体 POCO 业务逻辑答案

【问题标题】：Mocking concrete POCO business logic for Controller Tests模拟控制器测试的具体 POCO 业务逻辑
【发布时间】：2012-01-10 17:14:19
【问题描述】：

假设我有以下控制器：

    //
    // GET: /Courses/Edit/5
    public ActionResult Edit(int id)
    {
        Course course = courseService.GetCourseByID(id);
        if (course != null && course.userCanAccess())
        {
            // Do stuff...
        }
    }

if 语句被设计为一种简单的检查，以确保用户可以继续执行操作。 Course 实体本身提供了确定用户是否可以访问它的逻辑。这很好用，但确实让我遇到了一个问题：如何测试控制器。

我需要一种方法来确保 course.userCanAccess() 在我的控制器测试中返回特定结果。我的实体 POCO 没有接口，所以我不相信我可以模拟它们（如果这是错误的，请纠正我）。

我的想法是我可以为测试创建一个完整的 Couse 对象，该对象被配置为 userHasAccess() 将返回我想要的，但该方法依赖于 Course 的某些相关实体被“水合”，因此可能成为一件苦差事接线。

我是测试新手，所以不确定如何继续。

【问题讨论】：

标签： asp.net-mvc asp.net-mvc-3 unit-testing mocking moq

【解决方案1】：

如果它们有你想模拟的方法标记为虚拟，你可以模拟它们。

【讨论】：

【解决方案2】：

POCOs 不应包含任何业务逻辑。他们是“Plain Old CLR Objects”。

您的业务逻辑应该在一个服务层中，您可以将其注入到您的控制器中。

如果您需要向POCOs 添加额外的属性，那没关系（将它们标记为[NotMapped]），或者您可以（并且应该）使用ViewModels，Darin Dimitrov 可能会告诉您！

您认为POCOs 不应该需要接口是正确的。事实上，为POCOs 使用接口使得使用EntityFramework 导航属性几乎是不可能的（但实际上并非不可能，我已经做到了，尽管采用了一种非常蹩脚、笨拙的方式）。

稍后我可以更全面地回答，但现在我需要回家陪我的妻子和孩子！

【讨论】：

虽然我同意 Course 不是 POCO，但我不同意业务逻辑始终必须属于服务层。您可以在域层中使用服务模式，也可以将方法直接放在实体上。向实体添加方法可以丰富域模型，即使它会导致 Clr 对象不再是普通的旧对象。
公平点。我只是说，根据定义，POCO 不能包含业务逻辑。您可以将业务逻辑放在您喜欢的任何地方，但是一旦它进入 POCO，它就不再是 POCO。 :-)
我认为 POCO 一词的意思是它只是一个类，不依赖于除 CLR 之外的任何技术或框架。领域层类通常是 POCO，而 ViewModel 通常是 POCO。 ViewModel 不应该有任何业务逻辑（同意），如果你遵循 DDD，领域层类应该有业务逻辑......
@Dommer - 正如许多其他关于 SO 的问题中所述，这是不正确的。正如您所暗示的那样，POCO 并不是“普通旧数据对象”的同义词。有关此事的更多信息，请参阅 Martin Fowler 在 anemic domain model 上的讨论。
@Derek：我对POCO 一词的理解是，正如您所说，它确实是“普通旧数据对象”的同义词，我相信在上下文中使用它时几乎总是如此的 ASP.NET MVC。我读过很多 Martin Fowler 的书，我并不是说将业务逻辑放在域模型中是一个坏主意，我只是建议这样做意味着它不应该再被称为 POCO。在这个语义问题上，我显然错了，但我知道我在这方面并不是独一无二的。感谢您的澄清。