Unit testing 使用测试/资源文件比较单元测试输出=代码气味？

使用生成的文件（如电子表格或XML文件）作为单元测试中比较的源代码是否有代码味道

---

比如说，我们必须编写大量的类来生成各种XML文件，以便以后处理。单元测试将是大量重复的断言，

foo.getExpectedValue（）=expectedValue

。开发人员没有这样做，而是选择使用他们应该测试的代码来生成XML，然后将其复制到test/resources中，以便将来的所有测试将其作为对象加载到内存中，并对其运行断言。这是代码气味吗？

是的，我不会那么做。这违反了良好测试的原则。主要是，一个好的测试应该是

• 独立-不应依赖其他测试。如果后续测试必须等待第一个测试生成的文件，则测试不是独立的
• 可重复-这些测试由于文件/内存中的依赖性而引入片状。因此，它们可能无法一致地重复

---

也许，您可以退一步，看看是否需要对每个生成的XML进行单元测试。如果这些文件生成遵循相同的代码执行路径（没有逻辑上的差异），我就不会针对每种情况编写单元测试。如果这些XML生成是与业务相关的，那么我会考虑接受测试。 在您描述的测试中，有两种做法被归类为测试气味

首先，编写要测试的类用于创建XML文件，这些XML文件稍后用于判断正确性。通过这种方式，您可以发现类中是否有更改，但首先无法确定结果是否正确

为了避免任何误解：气味不是生成的文件被使用，而是这些文件是用测试中的代码生成的。只有在对初始运行结果进行彻底审查的情况下，这种方法才有意义。但是，这些审查必须在以后重新生成文件时再次进行

其次，使用完整的XML文件进行比较（生成或不生成）是另一个小测试。原因是，这些测试不是很集中。对XML生成的任何更改都将导致测试失败。这似乎是一件好事，但它甚至适用于所有类型的预期更改，例如缩进中的更改。所以，你们只有一个测试告诉你们“有些东西改变了”，而不是“有些东西失败了”

要让测试告诉你“失败了”，你需要更具体的测试。例如，只查看生成的XML的特定部分的测试。一些测试将查看XML结构，其他测试将查看数据内容。您甚至可以进行测试来检查缩进。但是，如何？例如，您可以使用正则表达式来查看生成的XML字符串中某些有趣的部分是否与您期望的一样

一旦您有了更集中的测试，那么在对代码进行预期修改的情况下剩下的结果将看起来不同：当您的更改成功时，许多测试用例中只有少数会失败，这将是针对您有意更改的行为部分进行测试的测试用例。所有其他测试仍然可以正常工作，并显示您的更改没有意外地破坏某些内容。相比之下，如果您的更改不正确，那么一些超出预期的测试将显示更改产生了意外的影响。

如果文件很小，您可以使用字符串读取器和写入器。一般来说，应该避免在单元测试中进行i/o。然而，我认为在一些非单元测试中使用文件没有什么错