对大块代码进行单元测试（映射、翻译等）

Question

我们对大部分业务逻辑进行单元测试，但仍停留在如何最好地测试一些大型服务任务和导入/导出例程上。例如，考虑将工资单数据从一个系统导出到第三方系统。为了以公司需要的格式导出数据，我们需要访问约 40 个表，这为创建测试数据和模拟依赖关系带来了噩梦般的情况。

例如，考虑以下内容（大约 3500 行导出代码的子集）：

public void ExportPaychecks()
{
   var pays = _pays.GetPaysForCurrentDate();
   foreach (PayObject pay in pays)
   {
      WriteHeaderRow(pay);
      if (pay.IsFirstCheck)
      {
         WriteDetailRowType1(pay);
      }
   }
}

private void WriteHeaderRow(PayObject pay)
{
   //do lots more stuff
}

private void WriteDetailRowType1(PayObject pay)
{
   //do lots more stuff
}

在这个特定的导出类中，我们只有一个公共方法 - ExportPaychecks()。这确实是对调用此类的人有意义的唯一操作...其他所有内容都是私有的（约 80 个私有函数）。我们可以将它们公开进行测试，但随后我们需要模拟它们来单独测试每个（即，如果不模拟 WriteHeaderRow 函数，您就无法在真空中测试 ExportPaychecks。这也是一个巨大的痛苦。

因为这是一个对于单个供应商来说，将逻辑移至域中是没有意义的。该逻辑在该特定类之外没有域意义。作为测试，我们构建了接近 100% 代码覆盖率的单元测试。但这需要将大量测试数据输入到存根/模拟对象中，再加上存根/模拟我们的许多依赖项，

我们有数百个导出和导入项。 减轻痛苦吗？我很想说“不对导入/导出例程进行单元测试”，然后再实施集成测试。

真的对这种类型的事情进行单元测试吗？如果是这样，有什么捷径可以 /strong> - 感谢大家的回答，我很想看到一个例子，因为我仍然没有看到有人如何将大文件导出之类的东西变成易于测试的代码块，而无需转换代码。陷入混乱。

Answer 1

这种（尝试的）单元测试风格，你试图通过一个公共方法覆盖整个巨大的代码库，总是让我想起外科医生、牙医或妇科医生，他们通过小开口执行复杂的操作。有可能，但并不容易。

封装是面向对象设计中的一个古老概念，但有些人将其推向极端，导致可测试性受到影响。还有另一个面向对象原则，称为开放/封闭原则，它更适合可测试性。封装仍然有价值，但不以牺牲可扩展性为代价 - 事实上，可测试性确实是只是开闭原则的另一种说法。

我并不是说您应该公开您的私有方法，而是说您应该考虑将您的应用程序重构为可组合的部分 - 许多相互协作的小类，而不是一个大的 交易脚本。您可能认为对于单一供应商的解决方案这样做没有多大意义，但现在您正在遭受痛苦，而这是一种出路。

当您在复杂的 API 中拆分单个方法时，经常会发生的情况是您还获得了很多额外的灵活性。一开始作为一次性项目的项目可能会变成一个可重用的库。

---

以下是关于如何针对当前问题进行重构的一些想法： 每个 ETL 应用程序必须至少执行以下三个步骤：

1. 从源中提取数据 转换
2. 数据
3. 将数据加载到目标中

（因此，名称ETL）。作为重构的开始，这为我们提供了至少三个具有不同职责的类：Extractor、Transformer 和 Loader。现在，不再是一个大类，而是三个具有更有针对性的职责。没什么乱七八糟的，而且已经更容易测试了。

现在放大这三个领域中的每一个，看看在哪里可以进一步划分职责。

• 至少，您需要源数据的每一“行”在内存中都有一个良好的表示。如果源是关系数据库，您可能想要使用 ORM，但如果不是，则需要对此类类进行建模，以便它们正确保护每行的不变量（例如，如果字段不可为空，则该类应保证如果尝试使用 null 值，则抛出异常）。此类具有明确的用途，并且可以单独进行测试。
• 对于目的地也是如此：您需要一个良好的对象模型。
• 如果源头正在进行高级应用程序端过滤，您可以考虑使用规范来实现这些过滤设计模式。这些往往也非常容易测试。
• 转换步骤是许多操作发生的地方，但是现在您已经拥有了源和目标的良好对象模型，可以通过映射器（同样是可测试的类）来执行转换。

如果您有许多源数据和目标数据“行”，则可以在映射器中进一步将其拆分为每个逻辑“行”等。

它永远不需要变得混乱，并且附加的好处（除了自动化测试之外）是对象模型现在更加灵活。如果您需要编写涉及两侧之一的另一个 ETL 应用程序，那么您至少已经编写了三分之一的代码。

Answer 2

关于重构，我想到了一些一般性的事情：

重构并不意味着您将 3.5k LOC 分成 n 个部分。我不建议将您的 80 个方法中的某些方法公开或类似的东西。它更像是垂直分割你的代码：

• 尝试分解独立的算法和数据结构，如解析器、渲染器、搜索操作、转换器、专用数据结构......
• 尝试弄清楚你的数据是否分几个步骤进行处理，并且可以构建在一种管道和过滤器机制或分层架构中。尝试找到尽可能多的层。
• 将技术（文件、数据库）部分与逻辑部分分开。
• 如果您有许多这样的导入/导出怪物，请了解它们的共同点，并将其分解并重复使用。
• 一般来说，您的代码可能过于密集，即它在太少的 LOC 中包含太多不同的功能。访问代码中的不同“发明”，并思考它们实际上是否是值得拥有自己的类的棘手设施。
  • 重构时，LOC 和类的数量都可能增加。
  • 尝试使类内部的代码真正简单（“婴儿代码”），而类之间的关系变得复杂。

因此，您根本不必编写覆盖整个 3.5k LOC 的单元测试。单个测试仅涵盖其中的一小部分，并且您将有许多彼此独立的小测试。

---

编辑

这是一个很好的重构模式列表。其中，一个很好地表达了我的意图：分解条件。

在该示例中，某些表达式被分解为方法。不仅使代码更易于阅读，而且您还获得了对这些方法进行单元测试的机会。

更好的是，您可以将此模式提升到更高的水平，并将这些表达式、算法、值等不仅分解为方法，还分解为它们自己的类。

Answer 3

您最初应该进行的是集成测试。这些将测试函数是否按预期执行，并且您可以为此访问实际数据库。

一旦有了安全网，您就可以开始重构代码以使其更易于维护并引入单元测试。

正如 serbrech 所提到的，有效地使用遗留代码将帮助您无休无止，我强烈建议您阅读它，即使对于新建项目也是如此。

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp /0131177052

我想问的主要问题是代码多久更改一次？如果它不频繁，那么真的值得努力引入单元测试，如果它经常更改，那么我肯定会考虑稍微清理一下它。

Answer 4

听起来集成测试可能就足够了。特别是如果这些导出例程一旦完成就不会改变或仅在有限的时间内使用。只需获取一些具有变化的示例输入数据，并进行测试来验证最终结果是否符合预期。

您的测试的一个问题是您必须创建大量的虚假数据。您可以通过创建共享夹具来减少这种情况（http://xunitpatterns.com/Shared%20Fixture .html）。对于单元测试，固定装置可能是要导出的业务对象的内存中表示，或者对于集成测试的情况，它可能是使用已知数据初始化的实际数据库。关键是，无论您如何生成共享固定装置，在每个测试中都是相同的，因此创建新测试只需对现有固定装置进行细微调整即可触发您想要测试的代码。

那么你应该使用集成测试吗？一个障碍是如何设置共享夹具。如果您可以在某处复制数据库，则可以使用 DbUnit 之类的工具来准备共享夹具。将代码分成几部分（导入、转换、导出）可能会更容易。然后使用基于 DbUnit 的测试来测试导入和导出，并使用常规单元测试来验证转换步骤。如果您这样做，则不需要 DbUnit 为变换步骤设置共享夹具。如果您可以将代码分为 3 个步骤（提取、转换、导出），至少您可以将测试工作集中在可能存在错误或稍后更改的部分。

Answer 5

我与 C# 无关，但我有一些想法你可以在这里尝试。如果您稍微拆分代码，那么您会注意到您所拥有的基本上是对序列执行的操作链。

第一个获得当前日期的报酬：

    var pays = _pays.GetPaysForCurrentDate();

第二个无条件处理结果

    foreach (PayObject pay in pays)
    {
       WriteHeaderRow(pay);
    }

第三个执行条件处理：

    foreach (PayObject pay in pays)
    {
       if (pay.IsFirstCheck)
       {
          WriteDetailRowType1(pay);
       }
    }

现在，您可以使这些阶段更加通用（抱歉伪代码，我不知道 C#）：

    var all_pays = _pays.GetAll();

    var pwcdate = filter_pays(all_pays, current_date()) // filter_pays could also be made more generic, able to filter any sequence

    var pwcdate_ann =  annotate_with_header_row(pwcdate);       

    var pwcdate_ann_fc =  filter_first_check_only(pwcdate_annotated);  

    var pwcdate_ann_fc_ann =  annotate_with_detail_row(pwcdate_ann_fc);   // this could be made more generic, able to annotate with arbitrary row passed as parameter

    (Etc.)

如您所见，现在您有了一组未连接的阶段，可以单独测试，然后以任意顺序连接在一起。这种连接或组合也可以单独测试。等等（即 - 您可以选择要测试的内容）

Answer 6

这是嘲笑一切的概念失败的领域之一。当然，单独测试每个方法将是一种“更好”的做事方式，但是将制作所有方法的测试版本的工作量与将代码指向测试数据库的工作量进行比较（如果需要，在每个测试运行开始时重置） ）。

这就是我在组件之间有很多复杂交互的代码中使用的方法，并且效果很好。由于每个测试将运行更多代码，因此您更有可能需要使用调试器逐步执行以准确找到出错的位置，但您无需付出大量额外的努力即可获得单元测试的主要好处（知道出了问题） 。

Answer 7

我认为托马斯·齐林斯基已经找到了答案。但如果你说你有3500行程序代码，那么问题就更大了。
把它分成更多的功能并不会帮助你测试它。然而，这是确定可以进一步提取到另一个类的职责的第一步（如果您对方法有好的名称，那么在某些情况下这可能是显而易见的）。

我想对于这样一个类，您需要处理一个令人难以置信的依赖项列表，以便能够将此类实例化到测试中。那么在测试中创建该类的实例就变得非常困难......
Michael Feathers 的《Working With Legacy Code》一书很好地回答了这些问题。
能够很好地测试代码的第一个目标应该是识别类的角色并将其分解为更小的类。当然，这说起来很容易，讽刺的是，如果不进行测试来确保修改安全，这是有风险的……

您说该类中只有 1 个公共方法。这应该可以简化重构，因为您不需要担心所有私有方法的用户。封装很好，但是如果您在该类中有这么多私有的东西，这可能意味着它不属于这里，您应该从该怪物中提取不同的类，您最终将能够进行测试。一点一点地，设计应该看起来更干净，并且您将能够测试更多的大代码。
如果您开始使用它，您最好的朋友将是一个重构工具，那么它应该可以帮助您在提取类和方法时不破坏逻辑。

迈克尔·费瑟斯 (Michael Feathers) 的这本书似乎又是你必读的:)
http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/ dp/0131177052

添加示例：

这个示例来自 Michael Feathers 的书，很好地说明了您的问题，我认为：

RuleParser  
public evaluate(string)  
private brachingExpression  
private causalExpression  
private variableExpression  
private valueExpression  
private nextTerm()  
private hasMoreTerms()   
public addVariables()  

显然，将方法 nextTerm 和 hasMoreTerms 公开是没有意义的。没有人应该看到这些方法，我们移动到下一个项目的方式绝对是类内部的。那么如何测试这个逻辑呢？

好吧，如果您发现这是一个单独的责任并提取一个类，例如 Tokenizer。这个方法将突然在这个新类中公开！因为这就是它的目的。然后测试这种行为就变得很容易......

因此，如果您将其应用到您的大段代码中，并将其片段提取到职责较少的其他类中，并且将这些方法公开会感觉更自然，那么您也将能够轻松地测试它们。
您说您正在访问大约 40 个不同的表来映射它们。为什么不将其分解为映射的每个部分的类？

推理我无法阅读的代码有点困难。您可能还有其他问题阻止您这样做，但这是我最好的尝试。

希望这有帮助
祝你好运 ：）

Answer 8

我真的很难接受您有多个大约 3.5 个 Klines 数据导出函数，并且它们之间根本没有通用功能。如果事实确实如此，那么单元测试可能不是您需要关注的。如果每个导出模块确实只做一件事，并且本质上是不可分割的，那么也许需要快照比较、数据驱动的集成测试套件。

如果存在共同的功能，则将它们中的每一个提取出来（作为单独的类）并单独测试它们。这些小辅助类自然会有不同的公共接口，这应该可以减少私有 API 无法测试的问题。

您没有提供有关实际输出格式的任何详细信息，但如果它们通常是表格、固定宽度或分隔文本，那么您至少应该能够将导出器拆分为结构和格式化代码。我的意思是，您将拥有类似以下内容的代码，而不是上面的示例代码：

public void ExportPaychecks(HeaderFormatter h, CheckRowFormatter f)
{
   var pays = _pays.GetPaysForCurrentDate();
   foreach (PayObject pay in pays)
   {
      h.formatHeader(pay);
      f.WriteDetailRow(pay);
   }
}

HeaderFormatter 和 CheckRowFormatter 抽象类将为这些类型的报告定义一个通用接口例如，各个具体子类（用于各种报告）将包含用于删除重复行的逻辑（或特定供应商所需的任何内容）。

另一种切片方法是将数据提取和格式化相互分开。编写代码，将各种数据库中的所有记录提取为中间表示形式，该中间表示形式是所需表示形式的超集，然后编写相对简单的过滤器例程，将 uber 格式转换为每个供应商所需的格式。

---

经过更多思考后，我意识到您已将其识别为 ETL 应用程序，但您的示例似乎将所有三个步骤结合在一起。这表明第一步是将事物分开，以便首先提取所有数据，然后翻译，然后存储。您当然可以至少单独测试这些步骤。

Answer 9

我维护了一些与您所描述的类似的报告，但数量没有那么多，数据库表也更少。我使用了一个三重策略，它的扩展性可能足以对您有用：

1. 在方法级别，我对我主观认为“复杂”的任何内容进行单元测试。这包括 100% 的错误修复，以及任何让我感到紧张的内容。

2. 在模块级别，我对主要用例进行单元测试。正如您所遇到的，这是相当痛苦的，因为它确实需要以某种方式模拟数据。我通过抽象数据库接口（即我的报告模块中没有直接的 SQL 连接）来实现这一点。对于一些简单的测试，我手动输入了测试数据，对于其他测试，我编写了一个记录和/或回放查询的数据库接口，以便我可以用真实数据引导我的测试。换句话说，我在记录模式下运行一次，它不仅获取真实数据，而且还为我在文件中保存快照；当我在播放模式下运行时，它会查阅此文件而不是真正的数据库表。 （我确信有模拟框架可以做到这一点，但由于我的世界中的每个 SQL 交互都有签名存储过程调用 -> Recordset，因此我自己编写它非常简单。）

3. 我很幸运能够访问具有完整生产数据副本的暂存环境，因此我可以通过对以前的软件版本进行完全回归来执行集成测试。

Answer 10

您是否查看过Moq？

来自该网站的引用：

Moq（发音为“Mock-you”或只是
“Mock”）是唯一的模拟库
.NET 从头开始​​开发到
充分利用.NET 3.5（即
Linq 表达式树）和 C# 3.0
特征（即 lambda 表达式）
使其成为最具生产力的，
类型安全且重构友好
可用模拟库。