TDD用于批处理：如何做？

我喜欢RoR等的“红色/绿色/重构”等。

我的日常工作涉及使用python和其他自定义工具批量处理来自第三方的超大文件。

这些文件的属性的流失率很高，因此很多修正/增强功能都经常被应用。

不存在通过具有预期结果的已知测试数据进行回归测试。最近的事情是对最后一批进行手工编码的新测试用例运行，请确保它不会爆炸，然后应用抽查和统计测试来查看数据是否仍然正常。

问>>如何将TDD原理引入这种环境？

仅供参考：单元测试不等同于TDD。TDD是一个包含单元测试的过程。

话虽如此，如果您打算实施单元测试，那么可以做很多事情：

所有新代码/增强功能均经过测试

这样，您就不必对所有已经存在的内容进行单元测试，因此实现单元测试的初期工作要小得多。

测试单个数据

测试可能包含大量数据的内容可能会导致很多极端情况和测试覆盖范围的空白。而是考虑0、1，许多选项。用0个元素，1个元素和许多元素测试“批处理”。对于1个元素，请测试该元素的数据可以包含的各种排列。

在此测试边缘情况（上限为单个元素的大小以及批中元素的数量）。如果您定期运行测试，并且具有长期运行的测试（大批量？），则大多数测试运行程序都允许进行分类，以便您可以单独运行这些测试用例（每晚？）。

那应该给您坚实的基础。

使用实际数据

像现在一样输入“实际的”以前使用过的数据并不是一个坏主意。只需用结构良好的测试数据进行补充，即可立即了解特定的故障点。如果无法处理实际数据，则可以检查批处理结果，进行单元测试以复制错误，然后使用有用的回归案例返回红色/绿色/重构。

它与任何其他环境相同。

将逻辑分成最小的粒度级别。这将为您提供一套流程规则，每条规则将涵盖流程所需的一项逻辑。

然后为每个规则编写一个测试。这些测试将失败。编写代码以修复测试。

您正在谈论的具有已知测试数据的回归测试不是单元测试。那将是集成测试，这与TDD不同。使用TDD，您可能只有一个测试来测试您是否可以加载文件，但是通常没有其他测试会真正接近带有测试数据的数据文件。相反，您将使用模拟对象来模拟执行特定规则所需的数据。

从良好的软件策略开始，然后应用TDD。

（免责声明：我可能误解了“搅动”或TDD，或两者都有。）

这是我建议的批处理“脏数据”的策略：指定-分类-执行。

• 以严格和狭窄的方式起草数据规范，但将覆盖大部分（例如80％或更多）传入数据。叫这个规范称为1。
• 进行分类模块（如果需要，可以使用TDD）来确定记录是否符合规范1。
  • 确保模块运行非常快。
  • 该模块应返回true / false：它满足所有规则，或者不满足。
• 开发执行模块（如果需要，可以使用TDD）来解析已知符合规范1的记录，以执行客户所需的任何任务。
• 应用分类1对所有传入数据。
  • 结果是每个记录一个布尔值。这基本上将传入的数据分为：规范1，或未知。
  • 客户需要时，对规格1数据应用执行1。
• 放宽规范1的规则，以接受剩余数据的80％。将此规范称为2。
• 开发分流2和执行2。将其应用于不符合规范1的任何数据。
• 根据需要重复许多级别，直到剩余数据足够小以至于每天都可以进行手动处理。

效率花絮：

保存与记录关联的所有“分类”结果（历史或当前）。如果自上次运行以来未修改Triage模块，则不必在旧数据上重新运行它。

“在进行TDD之前，您必须知道要构建的内容”提示：

指定分类-执行是一种使需求在每个级别上都可管理并允许将来增长的方法。

（如果有人知道这三个步骤的标准正确术语，请告诉我，我将编辑答案。）