unit-testing - TDD - 顶级函数有太多的模拟。我什至应该费心测试它吗？

Question

我有一个带有 Web 前端、WCF Windows 服务后端的 .NET 应用程序。该应用程序相当简单 - 它需要一些用户输入，然后将其发送到服务。该服务执行此操作 - 接受输入(Excel 电子表格)，提取数据项，检查 SQL DB 以确保这些项目不存在 - 如果它们不存在，我们向第三方数据供应商发出实时请求并检索结果，将它们插入数据库。它会在此过程中进行一些日志记录。

我有一个带有单个公共(public) ctor 和公共(public) Run() 方法的 Job 类。 ctor 获取所有参数，Run() 方法完成上述所有逻辑。每个逻辑功能都被拆分为一个单独的类 - IParser 进行文件解析，IConnection 进行与数据供应商的交互，IDataAccess 进行数据访问等。 Job 类具有这些接口(interface)的私有(private)实例，并使用 DI 来构造默认情况下实际实现，但允许类用户注入(inject)任何接口(interface)。

在实际代码中，我使用默认的ctor。在 Run() 方法的单元测试中，我使用通过 NMock2.0 创建的所有模拟对象。这个 Run() 方法本质上是这个应用程序的“顶级”函数。

现在这是我的问题/问题:这个 Run() 方法的单元测试很疯狂。我有三个要发送到 ctor 的模拟对象，每个模拟对象都对自己设定期望。最后我验证。我有几个 Run 方法可以采用的不同流程，每个流程都有自己的测试 - 它可以发现所有内容都已经在数据库中，而不是向供应商发出请求......或者可能会引发异常并且作业状态可能设置为“失败”......或者我们可能会遇到没有数据并且需要发出供应商请求的情况(因此需要进行所有这些函数调用)。

现在 - 在你冲我大喊“你的 Run() 方法太复杂了!”之前- 这个 Run 方法只有区区 50 行代码! (它确实调用了一些私有(private)函数；但整个类只有 160 行)。因为所有“真正的”逻辑都是在这个类上声明的接口(interface)中完成的。 然而，这个函数最大的单元测试是 80 行代码，有 13 次调用 Expect.BLAH().. _

这使得重构成为一个巨大的痛苦。如果我想改变这个 Run() 方法，我必须去编辑我的三个单元测试并添加/删除/更新 Expect() 调用。当我需要重构时，我最终会花费更多时间来创建模拟调用，而不是实际编写新代码。在这个函数上做真正的 TDD 会使它变得更加困难，如果不是不可能的话。这让我觉得根本不值得对这个顶级函数进行单元测试，因为这个类实际上并没有做太多逻辑，它只是将数据传递给它的复合对象(这些都是完全单元测试的，不需要 mock )。

那么 - 我是否应该费心测试这个高级功能？我这样做有什么好处？还是我在这里完全滥用模拟/ stub 对象？也许我应该放弃这个类的单元测试，而只做一个自动化的集成测试，它使用对象的真实实现和针对 SQL 查询的 Asserts() 来确保存在正确的最终状态数据？我在这里想念什么？

编辑:Here's the code - 第一个函数是实际的 Run() 方法 - 然后是我的五个测试，测试所有五个可能的代码路径。我出于 NDA 的原因对其进行了一些更改，但总体概念仍然存在。 您对我测试此功能的方式有任何发现错误，有什么建议可以更改以使其更好吗？ 谢谢。

Answer 1

我想我的建议与此处发布的大部分内容相呼应。

听起来好像您的 Run 方法需要进一步分解。如果它的设计迫使您进行比实际更复杂的测试，那是有问题的。请记住，这是我们正在谈论的 TDD，因此您的测试应该决定您的例程设计。如果这意味着测试私有(private)函数，那就这样吧。任何技术哲学或方法都不应该如此死板，以至于您无法做正确的事情。

此外，我同意其他一些海报，即你的测试应该被分解成更小的部分。问问自己，如果你是第一次编写这个应用程序并且你的 Run 函数还不存在，你的测试会是什么样子？该响应可能不是您当前的响应(否则您不会问这个问题)。 :)

您确实拥有的一个好处是该类中没有很多代码，因此重构它应该不会很痛苦。

编辑

刚刚看到您发布了代码并产生了一些想法(没有特定的顺序)。

SyncLock block 内的代码(IMO)太多。一般规则是在 SyncLock 中保持代码最少。是吗全部 必须上锁吗？

开始将代码分解成可以独立测试的函数。示例:如果 ID 存在于 DB 中，则从 List(String) 中删除 ID 的 ForLoop。有些人可能会争辩说 m_dao.BeginJob 调用应该在某种可以测试的 GetID 函数中。

是否可以将任何 m_dao 程序转换为可以自行测试的函数？我会假设 m_dao 类在某处有它自己的测试，但通过查看代码，情况似乎并非如此。它们应该与 m_Parser 类中的功能一起使用。这将减轻运行测试的一些负担。

如果这是我的代码，我的目标是将代码放到一个地方，其中 Run 中的所有单个过程调用都可以自行测试，并且 Run 测试只测试最终结果。给定输入 A、B、C:期望结果 X。给定输入 E、F、G:期望 Y。Run 如何到达 X 或 Y 的详细信息已经在其他程序的测试中进行了测试。

这些只是我的初步想法。我敢肯定有很多不同的方法可以采取。