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

Question

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

说我们不得不编写许多类，这些类产生各种XML文件供以后处理。单元测试将是<office>(Town) - Street, number</office> <office>(Town) - Street, number</office> <office>(Town) - Street, number</office> <office>(Town) - Street, number</office> 的大量重复断言​​。开发人员选择使用他们应该测试的代码来生成XML，而不是这样做，然后将其复制到测试/资源中，以便将来将所有测试作为对象加载到内存中并对其进行声明。这是代码气味吗？

Answer 1

Yes, I wouldn't do that. This is breaking principles of a good test. Mainly, a good test test should be;

• Independent - should not rely on other tests. If subsequent tests have to wait for a file generated by the first test,tests are not independent.
• Repeatable - these tests introduce the flakiness due to the file/in-memory dependency. Therefore, they may not be repeatable consistently.

Perhaps, you could take a step back and see whether you need to unit test every generated XML. If these file generation follow the same code execution path with (no logical difference), I wouldn't write unit test per each case. If these XML generation is business operation related, I would consider having acceptance tests.

Answer 2

您所描述的两种做法被归类为测试气味。

首先，您编写要测试的类用于创建XML文件，该XML文件随后用于判断正确性。这样，您可以找出类中是否有更改，但是首先不能确定结果是否正确。

为避免任何误解：气味不是使用生成的文件，而是使用受测试的代码生成文件。这种方法可能有意义的唯一方法是，如果要对初始运行的结果进行彻底的审查。但是，每当以后重新生成文件时，都必须再次重复这些审核。

第二，使用完整的XML文件进行比较（是否生成）是另一个小测试。原因是，这些测试不是很集中。对XML生成的任何更改都将导致测试失败。这似乎是一件好事，但它甚至适用于各种预期的更改，例如缩进的更改。因此，您只能进行测试，告诉您“某些更改”，而不是“某些失败”。

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

一旦您进行了更具针对性的测试，则在对代码进行有意修改的情况下，其余结果将看起来有所不同：成功完成更改后，只有少数几个测试用例将失败，而这些测试用例将具有针对您有意更改的部分行为进行了测试。所有其他测试仍然可以正常运行，并向您显示您的更改没有意外中断某些内容。相反，如果您的更改不正确，那么比预期的测试更多/其他的测试将向您显示该更改具有意外的效果。

Answer 3

如果文件小，则可以使用字符串读取器和写入器。通常，应该避免在 unit 测试中进行输入/输出。但是，我认为在一些非单元测试中使用文件没有错。