单元测试文件解析例程？答案

【问题标题】：unit testing file parsing routines?单元测试文件解析例程？
【发布时间】：2009-11-20 03:01:10
【问题描述】：

我在如何对文件进行单元测试时有点挣扎...假设我有一个包含 25 列的文件，其长度可能在 20 到 1000 条记录之间...我该如何编写针对那？该函数将文件作为字符串作为参数，并返回带有文件内容的DataTable...

我能想到的最好的办法是解析一个 4 记录文件，只检查左上角和右下角的“角落”......例如2 个顶部记录中的前几个字段和 2 个底部记录的最后几个字段......我无法想象必须为文件中的每个字段繁琐地手动键入断言语句。而且只做一个记录，每个字段看起来都一样弱，因为它没有考虑到多个记录文件或意外数据的情况。

当时这似乎“足够好”......但是现在我正在开发一个新项目，该项目本质上是解析来自 10 个不同来源的各种 PDF 文件，每个来源都有 4-6 种不同的格式他们的文件，所以大约有 40-60 个解析例程。我们最终可能会在未来完全自动化 25 个额外的资源。我们获取 PDF 并使用 3rd 方工具将其转换为 excel。然后我们坐下来分析输出中的模式，编写调用工具 API 的代码，获取 excel 文件并对其进行解析 - 剥离垃圾，对不同地方的数据进行排序，清理等等。

我如何对这样的东西进行单元测试？

【问题讨论】：

标签： unit-testing pdf parsing

【解决方案1】：

我不确定我是否完全理解这个问题，但这里有一个想法。收集一堆代表不同格式和边缘情况的示例文件。运行转换为您的 DataTables 并第一次手动检查 DataTables 以确保它们是正确的。然后将 DataTable 序列化为 XML 格式，并将它们与测试用例 PDF 文件一起存储在您的单元测试套件中。

您的自动化单元测试可以执行从 PDF 到 DataTable 的转换，并将结果与相应的“已批准”序列化 DataTable 表示进行比较。

随着时间的推移，您可以使用此方法建立一个测试文档库。单元测试中的失败表明对解析例程的更改已经破坏了特定的边缘情况。

但有一个“捕获”。我我的第一个例如，我在谈论 .NET 应用。然而，这个新项目与 40 可能'擦洗脚本'是用 VBA 编写的...... 输入是 Excel 电子表格和输出是一个 Excel 电子表格......如何我可以序列化这个吗？也许做一个整个文件的校验和？？？？

对于第二个示例，如果 Excel 电子表格不太复杂，您可以尝试逐个单元格比较例程，例如 this one；也许您可以将其包装到自定义 Assert.AreExcelWorksheetsEqual() 中。不过你是对的，校验和也可以工作。

【讨论】：

这是一个好主意——我没想到序列化/反序列化为 XML。然后我不需要对整个文件中的每个单元格进行一次 Assert() 调用。只需一个断言（或者如果需要循环）来确保它匹配
不过有一个“捕获”。我的第一个例子是 .NET 应用程序。但是，这个带有 40 个可能的“清理脚本”的新项目是用 VBA 编写的……输入是 Excel 电子表格，输出是 Excel 电子表格……我该如何序列化呢？也许对整个文件进行校验和？？？？
链接已失效... :(

【解决方案2】：

当您必须围绕数据样本构建单元测试时，请使用预期输出数据的第二个样本。 10K 行文本或兆字节的二进制文件。不要紧。

无论大小，您都可以只准备预期的输入样本和输出数据表。将其存储在源代码旁边的文件/脚本中。在测试中包括获取数据样本、对其进行处理以及使用一些通用比较工具或 SQL 语句将输出逐位与预期结果进行比较的步骤。

【讨论】：