使用 Moq 的单元测试未通过，对象为空，我错过了什么吗？

Question

我想要测试的类是我的 ArticleManager 类，特别是 LoadArticle 方法：

public class ArticleManager : IArticleManager
{
      private IArticle _article;

      public ArticleManger(IDBFactory dbFactory)
      {
            _dbFactory = dbFactory;
      }

      public void LoadArticle(string title)
      {
            _article = _dbFactory.GetArticleDAO().GetByTitle(title);

      }
}

我的 ArticleDAO 如下所示：

public class ArticleDAO : GenericNHibernateDAO<IArticle, int>, IArticleDAO
{
       public virtual Article GetByTitle(string title)
       {
           return Session.CreateCriteria(typeof(Article))
               .Add(Expression.Eq("Title", title))
               .UniqueResult<Article>();
       }
}

我的测试代码使用 NUnit 和 Moq：

[SetUp]
public void SetUp()
{
        _mockDbFactory = new Mock<IDBFactory>();
        _mockArticleDao = new Mock<ArticleDAO>();

        _mockDbFactory.Setup(x => x.GetArticleDAO()).Returns(_mockArticleDao.Object);

        _articleManager = new ArticleManager(_mockDbFactory.Object);
}


[Test]
public void load_article_by_title()
{
     var article1 = new Mock<IArticle>();

     _mockArticleDao.Setup(x => x.GetByTitle(It.IsAny<string>())).Returns(article1.Object);

     _articleManager.LoadArticle("some title");

     Assert.IsNotNull(_articleManager.Article);
}

单元测试失败，对象 _articleManager.Article返回 NULL。

我所做的一切都正确吗？

这是我的第一个单元测试，所以我可能遗漏了一些明显的东西？

我遇到的一个问题是，我想模拟 IArticleDao，但由于类 ArticleDao 也继承自抽象类，如果我只是模拟 IArticleDao 那么 GenericNHibernateDao 中的方法不可用？

Answer 1

前言：我不熟悉使用 Moq（这里是 Rhino Mocks 用户），所以我可能会错过一些技巧。

我正在努力遵循这里的一些代码；正如马克·西曼（Mark Seemann）指出的那样，我不明白为什么它会在当前状态下编译。请您仔细检查一下代码好吗？

值得注意的一件事是，您正在将 IDBFactory 的模拟注入到文章管理器中。然后，您进行链式调用：

_article = _dbFactory.GetArticleDAO().GetByTitle(title)

您尚未提供 GetArticleDAO 的实现。您仅模拟了 GetARticleDAO 调用之后发生的 LoadByTitle 位。测试中模拟和链式调用的组合通常表明测试将变得痛苦。

德墨忒尔定律

此处的要点：尊重德墨忒尔定律。 ArticleManager 使用 IDBFactory 返回的 IArticleDAO。除非 IDBFactory 做了一些非常重要的事情，否则您应该将 IArticleDAO 注入到 ArticleManager 中。

Misko 雄辩地解释了为什么挖掘协作者是一个坏主意。这意味着您需要执行额外的繁琐步骤来设置，并且还会使 API 更加混乱。

此外，为什么要将返回的文章作为字段存储在 ArticleManager 中？你能直接退货吗？

如果可以进行这些更改，则将简化代码并使测试变得更加容易 10 倍。

您的代码将变成：

public class ArticleManager : IArticleManager
{
      private IArticleDAO _articleDAO

      public ArticleManger(IArticleDAO articleDAO)
      {
            _articleDAO = articleDAO;
      }

      public IArticle LoadArticle(string title)
      {
            return _articleDAO.GetByTitle(title);
      } 
}

您将拥有一个更简单的 API，并且测试起来会容易得多，因为嵌套已经消失。

依赖持久性使测试变得更容易

在我对与持久性机制交互的代码进行单元测试的情况下，我通常使用 存储库模式并创建手动的、虚假的内存存储库以帮助测试。它们通常编写起来也很简单——它只是实现 IArticleRepository 接口的字典的包装。

使用这种技术允许您的 ArticleManager 使用假持久性机制，其行为与用于测试目的的数据库非常相似。然后，您可以轻松地用数据填充存储库，以帮助您以轻松的方式测试 ArticleManager。

模拟框架确实是很好的工具，但它们并不总是适合设置和验证复杂或连贯的交互；如果您需要在一个测试中模拟/存根多个内容（特别是嵌套的内容！），这通常表明测试过度指定，或者手动测试替身将是更好的选择。

测试很难

...在我看来，如果你从模拟框架开始，那就加倍困难。我见过很多人因为幕后发生的“魔法”而与嘲笑框架纠缠在一起。因此，我通常建议远离它们直到您对手卷存根/模拟感到满意为止/fakes/spies 等。

Answer 2

正如您当前提供的代码一样，我看不到它可以编译 - 有两个原因。

第一个可能只是一个疏忽，但 ArticleManager 类没有 Article 属性，但我假设它只是返回 _article 字段。

另一个问题是这行代码：

_mockArticleDao.Setup(x => x.GetByTitle(It.IsAny<string>())).Returns(article1.Object);

据我所知，这根本不应该编译，因为 ArticleDAO.GetByTitle 返回 Article，但你告诉它返回 IArticle 的实例（接口，而不是具体类）。

您在代码描述中是否遗漏了一些内容？

无论如何，我怀疑问题出在这个 Setup 调用上。如果您错误地指定了设置，则它永远不会被调用，并且 Moq 默认为其默认行为，即返回类型的默认值（即，引用类型为 null）。

顺便说一句，可以通过设置 DefaultValue 属性来更改这种行为，如下所示：

 myMock.DefaultValue = DefaultValue.Mock;

但是，这不太可能解决您的这个问题，所以您可以解决我上面指出的问题吗？我相信我们可以解决这个问题怎么了。

Answer 3

我不是 Moq 专家，但在我看来，问题在于你在嘲笑 ArticleDAO，而你应该嘲笑 IArticleDAO。

这与你的问题有关：

我遇到的一个问题是，我想模拟 IArticleDao，但由于类 ArticleDao 也继承自抽象类，如果我只是模拟 IArticleDao 那么 GenericNHibernateDao 中的方法不可用？

在模拟对象中，您不需要从 GenericNHibernateDao 类继承的方法。您只需要模拟对象来提供参与测试的方法，即：GetByTitle。您可以通过模拟提供此方法的行为。

如果方法已经存在于您尝试模拟的类型中，则 Moq 不会模拟方法。正如 API 文档中指定的：

任何接口类型都可以用于模拟，但对于类来说，只能模拟抽象成员和虚拟成员。

具体来说，您对 GetByTitle 的模拟将被忽略，因为模拟类型 ArticleDao 提供了此方法的（非抽象）实现。

因此，我给你的建议是模拟接口 IArticleDao 而不是类。

Answer 4

正如 Mark Seeman 所提到的，我无法让它“按原样”编译，因为 .GetByTitle 期望返回错误的类型，从而导致编译时错误。

纠正这个问题并添加缺少的 Article 属性后，测试通过了 - 让我认为你的问题的核心在某种程度上在翻译中丢失了，因为你把它写在了 SO 上。

然而，考虑到您正在报告问题，我想我应该提到一种方法，可以让 Moq 本身帮助您识别问题。

您得到 null _articleManager.Article 的事实几乎可以肯定是因为没有匹配的期望 .GetByTitle。换句话说，您指定的不匹配。

通过将模拟切换到严格模式，Moq 将在进行与期望不匹配的调用时引发错误。更重要的是，它将为您提供有关不匹配调用的完整信息，包括任何参数的值。有了这些信息，您应该能够立即确定为什么您的期望不匹配。

尝试使用严格的“失败”模拟集运行测试，看看它是否为您提供解决问题所需的信息。

这是测试的重写，模拟严格（折叠成单个方法以节省空间）：

[Test]
public void load_article_by_title()
{
    var article1 = new Mock<Article>();
    var mockArticleDao = new Mock<ArticleDAO>(MockBehavior.Strict); //mock set up as strict
    var mockDbFactory = new Mock<IDBFactory>(MockBehavior.Strict); //mock set up as strict

    mockDbFactory.Setup(x => x.GetArticleDAO()).Returns(mockArticleDao.Object);
    mockArticleDao.Setup(x => x.GetByTitle(It.IsAny<string>())).Returns(article1.Object);

    var articleManager = new ArticleManager(mockDbFactory.Object);
    articleManager.LoadArticle("some title");

    Assert.IsNotNull(articleManager.Article);
}