【问题标题】:Isolation during unit testing and duplicate code for test data单元测试期间的隔离和测试数据的重复代码
【发布时间】:2013-11-14 07:00:12
【问题描述】:

我正在开发一些 Java 应用程序并编写 JUnit 测试。我有一个关于单元测试的设计问题。我有一个类可以读取文件并通过读取不同的行并基于某种算法进行解析来创建名为 Song 的对象。我已经为此编写了一些单元测试。解析后的下一步是根据 Song 对象的某些属性将该歌曲实际转换为不同的格式。我有另一门课是翻译。有一种方法 translate 将 Song 对象作为输入。现在正在对翻译器进行单元测试。我需要一个具有所有有效属性的 Song 对象。我在这里感到困惑,我应该通过在解析器中放置相同的功能来创建一个新的 Song 对象,还是应该调用解析器服务来为我做这件事。如果我采取第二种选择,我觉得它不会被孤立。但在第一个选项中,它就像重复的代码。有人可以指导我吗?

【问题讨论】:

  • 为什么你不能通过调用它的构造函数来创建一首歌曲,然后调用你的翻译器?为什么你需要读取一个文件来创建一个新的 Song 对象?
  • @JBNizet 我理解您的评论,但 Song 对象不是一个简单的对象,具有一些名称和 id 之类的属性。它也有一些反映数字信号的字符串。算法将此数字信号转换为特定字符串。并且在没有算法的情况下创建该字符串以便翻译器可以正确翻译它是困难的并且可能是肮脏的。万一明天我们生成数字到字符串的方式会发生变化。更新翻译测试将是一团糟,也很难维护。
  • 好的。然后我会在测试源中放置一个测试文件并解析它以创建一首测试歌曲。当然,您的测试也将依赖解析器,但我没有看到任何更好的解决方案。

标签: unit-testing tdd


【解决方案1】:

当数据很复杂时,使用 Builder 为 SUT 调用创建输入数据并没有错,但是我在这里看到了 2 个风险。

  • 如果构建器失败,您的测试也会失败,但应该不会。正如您所说,单元测试应该与外部代码隔离。
  • 如果您使用代码覆盖率作为衡量单元测试效果的指标(我并不是说这是正确的),通过查看构建器的覆盖率,您会很容易认为它已经过测试,但显然不是.

我认为没有适合所有场景的最佳解决方案。如果输入数据不是很复杂,请尝试“手动”构建它,否则使用构建器。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-05-16
    • 2010-12-03
    • 1970-01-01
    相关资源
    最近更新 更多