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

时间:2011-05-18 18:47:41

标签: java xml testing properties

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

解决方案是将数据放在java源文件中,这样我就可以减少测试并且仍然可以进行编译时检查。怎么样?

或者loading the exepected results as resources是更好的方法吗? .properties文件不够好,因为每个键只能有一个值。 commons-config是可行的吗?

我更喜欢一个简单的解决方案,其中我为每个键命名属性,因此对于每个条目,我可能有一个doc-lengthnumFound属性值(听起来像xml节点的元素)?

你是怎么做到的?

3 个答案:

答案 0 :(得分:3)

你必须记住维持这样的测试。在使用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的文档中,包括表格?

答案 1 :(得分:2)

是的,使用预期结果的资源(以及设置数据)效果很好并且很常见。

XML可能是一种有用的格式 - 层次结构当然可以提供帮助(每个测试方法一个元素)。这取决于具体情况,但绝对是一种选择。或者,JSON可能更容易。在序列化API方面,您对什么感到满意?

答案 2 :(得分:2)

鉴于您提到您通常会测试某个数据库操作是否返回预期输出,您可能需要查看使用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可能会为您提供您尚未自行实现的其他功能。