我应该使用实际或样本数据进行单元测试吗？

Question

我正在为遗留应用程序的输出编写一个解析器，因为没有关于文件语法的规范，我尽可能多地获取这些文件的样本。

现在我在实现解析器之前编写单元测试（因为没有其他理智的方法可以做到这一点），但我不确定是否应该：

• 使用应用程序生成的真实文件，从中读取并将输出与我将以json格式存储在另一个文件中的输出进行比较。
• 或者创建一个带有标记的示例字符串和我想测试的可能性以及带有预期输出的dict（这是python）。

我倾向于使用第二种选择，因为我只测试我需要的东西，没有实际文件中包含的所有“真实世界”数据，但我担心我会忘记测试一种可能性或另一个。

您怎么看？

Answer 1

我的建议是两者都做。编写一组集成测试，运行所有具有预期输出的文件，然后使用预期输入进行单元测试，以隔离解析逻辑。

我建议首先编写集成测试，以便在外面编写解析器，看到一堆失败的测试可能会贬低，但它会帮助你更早地隔离边缘情况。

是的，我认为这是一个很好的问题。我最近遇到了类似的问题，它将大型xml提要从上游系统转换为专有格式。我的解决方案是为完整的feed编写一组集成黑盒测试，测试记录计数和其他高级别成功指标，然后将输入分解为越来越小的块，直到我能够测试数据的所有排列。只有这样，我才能很好地理解如何构建解析器。

Answer 2

在测试场景中，您应该小心使用生产数据。例如，如果所有用户都从测试环境收到电子邮件，那么这可能是一场灾难。在某些情况下，开发人员可以访问prod数据也可能是不道德的，即使用户无法知道这一点。考虑医疗，银行，大学等级类型的情景。

我的回答是你应该使用接近prod数据的数据。如果您想使用实际的prod数据，则需要根据上述情况对其进行清理。

Answer 3

不要忘记构建测试，以便在知道测试时添加其他可能性（即回归测试）。

Answer 4

使用您提供的第二个解决方案将允许您控制预期和返回的内容，这是单元测试的理想选择。在创建自动化测试时，最好尽可能避免手动交互 - 直观地扫描结果是您应该尽可能避免的做法之一（假设这是“比较”的意思）。

Answer 5

生产数据可以是一个很好的起点（假设它不是敏感信息），因为很有可能你自己无法想到所有可能的排列。但是，一旦获得了良好的工作数据集，请将其保存在静态的某个位置，如文件。然后让测试从那里获得，而不是从生产环境动态获取。这样，您每次都可以使用一组已知的输入运行测试。

备选方案，即时获取测试输入的生产数据，充满了问题。数据的变化可能导致测试通过一次，但是由于输入发生了变化，导致测试失败。