如何指定 JUnit 测试依赖项？答案

【问题标题】：How can I specify JUnit test dependencies?如何指定 JUnit 测试依赖项？
【发布时间】：2011-02-04 19:00:16
【问题描述】：

我们的工具包有超过 15000 个JUnit 测试，如果其他测试失败，许多测试都会失败。例如，如果方法 X.foo() 使用来自 Y.bar() 的功能并且 YTest.testBar() 失败，那么 XTest.testFoo() 也会失败。显然，XTest.testFoo() 也可能因为 X.foo() 特有的问题而失败。

虽然这很好，而且我仍然希望两个测试都运行，但如果可以使用指向 YTest.testBar() 的 XTest.testFoo() 来注释测试依赖关系，那就太好了。这样，我们可以立即看到 X.foo() 使用的哪些功能也失败了，哪些没有。

在 JUnit 或其他地方有这样的注解吗？比如：

public XTest {

  @Test
  @DependsOn(method=org.example.tests.YTest#testBar)
  public void testFoo() {
     // Assert.something();
  }

}

【问题讨论】：

这是一个古老的线程，但是：如果 X.foo() 使用 Y.bar()，则测试必须（！）模拟 Y.bar()，否则您的测试不是单元测试（但是一个集成测试）。单元测试的整个想法是没有任何依赖关系。但是，我来这里是有原因的 ;-)

标签： java unit-testing junit

【解决方案1】：

JExample 和 TestNG 有类似的东西。

我不知道它有多大用，但如果你尝试过，请回来告诉我们它是否有用。

【讨论】：

是的，这似乎是一个很好的开始：chem-bla-ics.blogspot.com/2010/08/…
它在 ClassA.methodA() 调用 ClassB.methodB() 并且两者都需要大量时间的情况下很有用。在这种情况下，您可以指定 testMethodA() 依赖于 testMethodB()，即如果 testMethodB() 失败，testMethodA() 也会失败不执行。
@Cherry：听起来像是不写fast tests的借口。改进设计的一些选项：(1) 使 methodB 快速，(2) 使 methodA 不依赖于 methodB，(3) 在测试 ClassA 时使用 ClassB 的测试替身。
不错的链接在这里列出所有答案，想知道这些链接的有效期多久

【解决方案2】：

有一个对 JUnit 的贡献可以解决这个问题：https://github.com/junit-team/junit.contrib/tree/master/assumes

【讨论】：

这似乎还没有在 maven Central 中可用（参见 search.maven.org/#search%7Cga%7C1%7Cjunit-contrib）。你如何使用它？还是你现在用别的东西？

【解决方案3】：

org.junit.FixMethodOrder

@FixMethodOrder(MethodSorters.NAME_ASCENDING) 这在您的单元测试类之上。

您可以将方法命名为 public void step1_methodName 等

【讨论】：

不完全是问的。例如在 Spring Boot 的集成测试中，如果有 10 个测试并且上下文加载失败，我想跳过其他测试，因为每个测试都会尝试再次加载上下文，所以如果上下文加载失败，我希望所有测试都失败作为第一次测试...

【解决方案4】：

您可以声明test dependencies in TestNG，语法与您的示例几乎相同。我不认为 JUnit 提供了类似的东西。

【讨论】：

【解决方案5】：

在behavior driven design 库jBehave 中有一个关键字GivenScenarios，它可以导入在主场景之前运行的场景列表。这提供了一个定义依赖关系并有一个故障点的机会。 jBehave 的日志记录会告诉您测试是否在依赖项或主体部分失败。

【讨论】：

【解决方案6】：

~~我真的不知道这样的事情。~~（编辑：你每天都会学到新东西:)）在我看来，这并不是一件坏事（虽然我可以看到它很有用，尤其是当 JUnit 用于其他形式的自动化测试时 - 例如，集成测试）。 IMO，您的测试并不是严格意义上的“单元测试”（至少不是X#foo() 的测试）。 X#foo() 的测试应该成功还是失败，具体取决于仅取决于 X#foo() 的实现。它不应该依赖于Y#foo()。

在你的位置上我要做的是模拟 Y，并以非常简单、受控的行为实现类似 MockY#foo() 的东西，并在 X#foo() 的测试中使用它。

也就是说，通过 15,000 次测试，我可以看出重构是多么痛苦。 :)

【讨论】：

我不明白为什么单元测试不能有依赖关系......我们的工具包定义了数据对象和算法......如果数据对象失败，您如何期望算法自动纠正呢？也许这两种方法 foo() 的命名具有误导性......
只有严格的模拟测试不会表现出任何相互依赖关系（它们仍然可能......）。一般来说，这种依赖总是可能的，并且必须反映 OO 设计中的依赖。我相信在所有测试中维护这样的注释会增加复杂性而没有显着的好处，但是在一些核心案例中使用这样的注释可能会有好处。