对“复杂”单元进行单元测试的正确方法应用服务

Question

我有一个应用程序服务（即大型方法）负责协调多个业务对象之间的交互。本质上，它从一个包含客户信息和发票的系统中获取 DTO，并将其转换并根据各种业务规则将其导入到不同的系统中。

public void ProcessQueuedData()
    {
       var queuedItems = _importServiceDAL.LoadQueuedData();

       foreach (var queuedItem in queuedItems)
       {
           var itemType = GetQueuedImportItemType(queuedItem);

           if (itemType == QueuedImportItemType.Invoice)
           {
               var account = _accountDAL.GetAccountByAssocNo(queuedItem.Assoc);
               int agentAccountID;

               if (!account.IsValid)
               {
                   agentAccountId = _accountDAL.AddAccount(queuedItem.Assoc);
               }
               else
               {
                   agentAccountId = account.AgentAccountID;
               }

               /// Do additional processing TBD
           }
       }
    }

对于单元测试，假设服务中的整个流程应该逐步进行细粒度测试是否正确，类似于以下内容？

ImportService_ProcessQueuedData_CallsDataAccessLayer_ToLoadQueue

ImportService_ProcessQueuedData_WithQueuedItemToProccess_ChecksIfAccountExists

ImportService_ProcessQueuedData_WithInvoice_CallsDALToCreateAccountIfOneDoesNotExist

这是一个典型的测试：

    [TestMethod()]
    public void ImportService_ProcessQueuedData_WithInvoice_CallsDALToCheckIfAgentAccountExists()
    {
        var accountDAL = MockRepository.GenerateStub<IAccountDAL>();
        var importServiceDAL = MockRepository.GenerateStub<IImportServiceDAL>();

        importServiceDAL.Stub(x => x.LoadQueuedData())
            .Return(GetQueuedImportItemsWithInvoice());

        accountDAL.Stub(x => x.GetAccountByAssocNo("FFFFF"))
            .IgnoreArguments()
            .Return(new Account() { AgentAccountId = 0 });

        var importSvc = new ImportService(accountDAL, importServiceDAL);

        importSvc.ProcessQueuedData();

        accountDAL.AssertWasCalled(a => a.GetAccountByAssocNo("FFFFF"), o => o.IgnoreArguments());
        accountDAL.VerifyAllExpectations();
    }

我的问题是我最终在每个测试中都做了太多设置一点。这是正确的方法吗？如果是，有哪些指示可以避免在每个粒度测试中重复所有这些设置？

Answer 1

我对你的具体应用了解不多，所以我无法提出任何具体的建议。也就是说，这种面向过程的测试听起来像是使用 Model- 的良好候选者基于测试技术。我熟悉 ModelJUnit 工具（公平披露：不久前，我被聘为该工具的 Java 开发人员，但是似乎有一个名为 NModel< 的等效工具/a> 适用于 C#，以及随附的书籍 C# 中基于模型的软件测试和分析。我这么说的原因是，也许您可​​以随机遍历整个过程，将您的设置代码全部放在一个位置，并允许抽象测试生成为您完成大部分其余的艰苦工作。

Answer 2

就我个人而言，我会尝试测试所有代码段，但不一定将每个部分都作为自己的测试。一项测试检查具有有效帐户的发票是否通过。第二个测试检查具有无效帐户的发票是否创建新帐户。当然，我会模拟 dals，因此不会将数据添加到数据库中。这还允许模拟异常和不应执行任何操作的情况（队列中没有任何内容，或者可能没有发票。）

Answer 3

我同意佩德罗的观点。您的第一个示例测试 (ImportService_ProcessQueuedData_CallsDataAccessLayer_ToLoadQueue) 是不必要的，因为其他测试将隐式测试 LoadQueuedData 是否被调用 - 如果没有，它们将没有可操作的数据。您希望对每个路径进行测试，但不需要对方法中的每一行代码进行单独的测试。如果条件分支有 6 条路径，则需要 6 次测试。

如果我想真正变得更有趣，我还可以考虑利用对象多态性来减少 if 语句的数量并简化测试。例如，您可以为每个 QueuedImportItemType 有一个不同的“处理程序”，并将处理该类型的项目的逻辑放在此处，而不是您的大 Process 方法。拆分迭代逻辑以及如何处理每种类型的项目使它们更容易单独测试。