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

编写测试我期望测试过的方法返回某些输出。通常我会检查给定的数据库操作，我会得到一个特定的输出。我的做法通常是在测试中将数组写作快速地图/属性文件。该解决方案非常快速，不易受外部文件的运行时更改以加载预期结果的影响。哪里存储预期的测试输出？

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

或者是loading the exepected results as resources更好的方法？ .properties文件不够好，因为每个键只能有一个值。是commons-config要走的路吗？

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

你如何去做这件事？

来源

2011-05-18 simpatico

有趣的问题！我们在这里所做的所有测试都是使用静态数据。在这种情况下，在测试代码中定义的预期结果工作正常。想知道这个！ – cheekoo 2011-05-18 18:50:19

+1 |评论：一个关键字可以有一个值，但该值可以表示由逗号分隔的多个值 – VirtualTroll 2011-05-18 18:54:03

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

XML对你来说可能是一种有用的格式 - 层次结构当然可以帮助（每个测试方法一个元素）。这取决于确切的情况，但它绝对是一种选择。或者，JSON可能会更容易。就序列化API而言，您感觉舒适吗？

来源

2011-05-18 18:55:51

“在串行化API方面，您感觉如何？”没有？我之前已经解析过XML和CSV（仅限JSON），但他们都是......我每次都查找（〜罕见）..你为了参考而发布了一些示例代码？ – simpatico 2011-05-18 19:18:10

@simpatico：如果不知道需要什么，很难做到这一点，坦率地说，我不想回到Java XML API中，除非我必须:(绝对看像JDom，而不是内置的XML API。 – 2011-05-18 19:21:59

那你去吧，xml解析不是一个简单的解决方案！ – simpatico 2011-05-18 19:24:29

既然你提到你通常在测试某一个DB操作返回预期的输出，你可能想看看使用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可能会为您提供您还没有自行实现的其他功能。

来源

2011-05-18 19:11:15

@matt：听说过“用代码证明”之前？ – simpatico 2011-05-18 19:21:38

呃 - 证明什么？这个库可能对某人有用？或者如何使用它？链接到DBUnit入门页面在我的回答中，我打算这么做，我不能希望提供更好的关于如何使用DBUnit的示例，而不是项目文档中出现的示例 – 2011-05-18 20:01:13

@matt - 如果我不测试数据库（如现在）米斯蒂一个servlet（该BTW有一个索引/数据库后面）并检查给定的查询，我得到预期的结果？ – simpatico 2011-05-19 08:06:34

你必须记住维护这样的测试。在使用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（看起来你不再进行单元测试，所以验收测试框架应该没问题），其中测试存储在维基文档中，包括表格？

来源

2011-05-18 19:11:51

我已经找到了完全相反的结果 - 我发现当它不是*字符串时，查看数据的测试数据要容易得多，它要么会发生级联cruft，要么全部在一行上，并且可能会需要逃避。此外，当您使用单独的文件时，更容易让其他工具检查这些文件是否有效 - 最终不会追逐无效的XML字符串。 – 2011-05-18 19:23:10

我和Jon在这一个。另外，无论何时想要更改数据，嵌入在源代码中的测试数据都需要重新编译。 – 2011-05-18 20:02:30

这就是q的症结所在！我有一个csv的数据，然后在很长一段时间后回来测试（显然我使用的是-DskipTests），花了我很长时间才发现测试确实是正确的，但问题是我偶然修改了测试..之后，我把所有的csv放在代码中，那个jar总是可以工作，但是这个类现在变得臃肿了，而且编辑器包装它变得太慢而无法导航。 – simpatico 2011-05-18 20:17:55

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

回答

相关问题