在哪里存储测试的预期输出？

Question

编写测试我希望测试的方法返回某些输出。通常我会检查对于给定的数据库操作我是否得到了特定的输出。我的做法通常是在测试本身中将数组编写为快速映射/属性文件。 该解决方案速度很快，并且不易受到外部文件运行时更改的影响，以从中加载预期结果。

解决方案是将数据放在 java 源文件中，这样我就可以减少测试的膨胀，并且仍然得到编译时检查的测试。这个怎么样？

或者将预期结果加载为资源< /a> 更好的方法？ .properties 文件不够好，因为每个键只能有一个值。 commons-config 是正确的方法吗？

我更喜欢一个简单的解决方案，其中我为每个键的属性命名，因此对于每个条目，我可能有一个 doc-length 和 numFound 属性值（听起来像一个 xml 节点）？

你怎么办？

Answer 1

鉴于您提到您通常正在测试某个数据库操作是否返回预期输出，您可能需要查看使用 DBUnit：

 // Load expected data from an XML dataset
    IDataSet expectedDataSet = new FlatXmlDataSetBuilder().build(new File("expectedDataSet.xml"));
    ITable expectedTable = expectedDataSet.getTable("TABLE_NAME");

    // Assert actual database table match expected table
    Assertion.assertEquals(expectedTable, actualTable);

DBUnit 在某些操作完成后比较表的状态，并断言表中的数据与预期的 DataSet 匹配。用于与实际表状态进行比较的 DataSet 最常见的格式可能是使用 XmlDataSet，其中预期数据是从 XML 文件加载的，但还有其他格式子类也是如此。

如果您已经在进行这样的测试，那么听起来您可能已经编写了大部分相同的逻辑 - 但 DBUnit 可能会免费为您提供您自己尚未实现的附加功能。

Answer 2

您必须记住维护此类测试。在使用 Spring-WS 测试支持编写了几个 Web 服务测试之后，我必须承认，在外部 XML 文件中存储请求（测试设置）和预期响应并不是一个好主意。每个请求-响应对都具有与测试用例相同的名称前缀，因此一切都是自动化的并且非常干净。但重构和诊断测试失败仍然变得痛苦。一段时间后，我意识到将 XML 作为 String 嵌入到测试用例中，虽然很难看，但更容易维护。

在您的情况下，我假设您调用一些数据库查询并获得响应的地图列表。编写一些不错的 DSL 来对这些结构进行断言怎么样？实际上， FEST-Assert 对此非常有用。

假设您测试以下查询（我知道这是过于简化的）：

List<Map<String, Object>> rs = db.query("SELECT id, name FROM Users");

那么您可以简单地写：

assertThat(rs).hasSize(1);
assertThat(rs.get(0))
  .hasSize(2)
  .includes(
    entry("id", 7),
    entry("name", "John")
  )
);

当然它可以而且应该进一步简化以更好地满足您的需求。在一个屏幕上拥有完整的测试场景而不是从一个文件跳转到另一个文件不是更容易吗？

或者也许你应该尝试 Fitnesse （看起来你不再进行单元测试，所以验收测试框架应该没问题），其中测试存储在类似 wiki 的文档中，包括表格？

Answer 3

是的，使用资源来获得预期结果（以及设置数据）效果很好，而且很常见。

XML 很可能是一种对您有用的格式 - 分层结构肯定会有所帮助（每个测试方法一个元素）。这取决于具体情况，但这绝对是一个选择。或者，JSON 对您来说可能更容易。就序列化 API 而言，您对什么感到满意？