【问题标题】:Dumping "real-world" scenarios out for unit testing将“真实世界”场景转储出来进行单元测试
【发布时间】:2009-09-03 22:23:52
【问题描述】:

我目前正在调试一些相当复杂的持久性代码,并尝试增加测试覆盖率。

我在生产代码中发现的一些错误需要大型且非常具体的对象图才能重现。

虽然从技术上讲,我可以在测试中写出大量实例化代码来重现特定场景,但我想知道是否有工具可以为我做到这一点?

我想我特别希望能够在我的调试器框架中转储一个对象(可能是 xml),然后使用一些东西加载到 XML 中并创建对象图以进行单元测试(例如, xStream 等)。

谁能推荐在这种情况下有用的工具或技术?

【问题讨论】:

  • 真的没有简单的场景可以重现错误行为吗?如果不是,我会将其视为功能测试。有了这种数据来触发错误,恕我直言,我们有点超出了“单元”级别。
  • @Yishai - 是单元测试还是功能测试重要吗?无论哪种情况,他都希望自动化该测试用例。
  • @ChrisW - 一旦你开始从功能测试的角度来思考它,就会打开一套完全不同的工具,你就会开始以不同的方式思考这个问题。它可能不会改变最终答案,但应该会改变我们对问题的看法。

标签: java unit-testing


【解决方案1】:

我已经使用ObjectOutputStream 完成了这种事情,但是 XML 应该可以正常工作。您需要使用可序列化的树。您也可以尝试 JAXB 或 xStream 等。我认为这很简单。如果您的代码中有一个位置可以以有利于您的测试的形式构建结构,请在其中注入序列化代码,并将所有内容写入文件。然后,删除注入的代码。然后,为了测试,加载 XML。您可以将文件填充到某个类路径中。我通常使用资源或配置目录,并使用 Thread.currentThread().getContextClassLoader().getResourceAsStream(name) 获取流。然后反序列化这些东西,你就可以开始了。

【讨论】:

  • 使用 ObjectOutputStream 是一个很好的解决方案,除非你改变你的类,然后你需要重新生成整个对象图并再次序列化它
  • 没错。我通常将注入的代码留在某处。与家庭项目相比,我会更正式地将其保留在工作环境中。
  • +1 你可以补充一点:1) 任何形式的对象序列化在面对影响表示的类的变化时都是脆弱的,2) 使用 XML 优于 ObjectOutputStream 的优点是它更容易使用 XML 或文本编辑器“修复”由这种脆弱性引起的任何问题。
【解决方案2】:

XStream 在这里有用。它允许您几乎将任何 POJO 转储到 XML 或从 XML 转储,而无需实现接口/注释等。我唯一头疼的是内部类(因为它会尝试序列化引用的外部类)。

【讨论】:

    【解决方案3】:

    我猜你所有的数据都保存在数据库中。您可以使用一些测试数据生成工具让您的数据库充满测试数据,然后以 SQL 脚本的形式导出该数据,然后在集成测试开始之前进行预加载。

    您可以使用 DBUnit 在单元测试中预加载数据,它还有许多选项可以在测试开始前验证数据库结构/数据。 http://www.dbunit.org/

    对于在数据库中生成测试数据,您可以使用许多商业工具。我不知道有什么好的免费工具可以处理预定义的数据列表、具有预定义分布的随机数据、来自其他表的外键使用等功能。

    【讨论】:

    • 如果不清楚的话:db:unit 有一种简单的方法可以将数据库的当前状态转储为它读取的任何格式。
    【解决方案4】:

    我不了解 Java,但如果您更改类的实现,那么您可能无法再反序列化旧的单元测试(这些测试是从旧版本的类中序列化的)。因此,如果您将来更改类定义,您可能需要在迁移单元测试数据方面付出一些努力。

    【讨论】:

      猜你喜欢
      • 2020-01-19
      • 1970-01-01
      • 2018-02-01
      • 2017-01-31
      • 1970-01-01
      • 1970-01-01
      • 2022-08-20
      • 2017-12-28
      • 1970-01-01
      相关资源
      最近更新 更多