【问题标题】:Has JUnit4 begun supporting ordering of test? Is it intentional?JUnit4 是否开始支持测试排序?是故意的吗?
【发布时间】:2011-12-12 08:30:46
【问题描述】:

JUnit(实际上是 JUnit 4)的新手,遇到了执行测试的套件方式

@RunWith(Suite.class)
@Suite.SuiteClasses(
        {                               
                CreateNewProfile.class,
                EditProfile.class,

        })
public class ProfileTestSuite {

}

这是我在新雇主浏览测试代码库时遇到的代码示例。 在执行期间,我资助-首先执行 CreateNewProfile 测试,然后执行 EditProfile, 这确实是有道理的,但它会在测试之间引入依赖关系。

几个月以来,我一直在遵循非依赖测试机制(尽管我曾经使用 TestNG 而不是 JUnit),并且希望 EditProfile 也能够单独执行。也就是说,编辑配置文件应该负责创建配置文件,然后对其进行编辑,然后断言操作。

我的问题是 - Junit 4 引入了测试排序功能。这个功能是有意的还是一个复活节彩蛋,我一直觉得 JUnit = 独立测试。

【问题讨论】:

    标签: java junit junit4


    【解决方案1】:

    JUnit 4.11 现在支持使用 @FixMethodOrder 注解指定执行顺序。

    【讨论】:

      【解决方案2】:

      您可以扩展套件运行器:

      public class MySuite extends Suite {
      
          public SuiteRunner(Class<?> klass, RunnerBuilder builder) throws InitializationError {
              super(klass, builder);
          }
      
          @Override
          protected List<Runner> getChildren() {
              List<Runner> children = super.getChildren();
              ... here modify the children list - you can remove or reorder test...
              return children;
          }
      }
      

      然后注释您的套件:

      @RunWith(MySuite.class)
      @Suite.SuiteClasses({                               
              CreateNewProfile.class,
              EditProfile.class})
      public class ProfileTestSuite { }
      

      标有@Ignore 的测试将由IgnoredClassRunner 表示,而常规测试将由BlockJUnit4ClassRunner 表示(或您将对其进行注释的任何运行器 - 这可能是BlockJUnit4ClassRunner 的扩展)。

      您可以从 runner 获取测试类。然后你可以使用自己的注解。

      【讨论】:

        【解决方案3】:

        没有 JUnit 不支持测试排序,除非以您所说的方式,通过 Suite。 这仅定义了测试 classes 的执行顺序。这已经存在很长时间了,包括 JUnit 3 Suite 类。

        为了更完整的解释,这里我们需要讲三件事:

        1. 测试套件中测试类的排序
        2. Eclipse 或 Maven 通过反射找到测试类时的排序
        3. 测试类中测试方法的顺序(用@Test 注释)。

        测试套件中测试类的顺序

        当您指定要在测试套件中执行的类列表时,您就是在定义一个数组,这些测试类将按顺序执行,除非您进行并行执行。不幸的是,这允许在您的测试类之间引入依赖关系。

        通过反射找到测试类时的排序

        在类路径中搜索类时,不能保证找到它们的顺序,因此不能依赖。进行搜索的实际上不是 JUnit,而是 Eclipse Junit 插件、maven surefire 或 failsafe。

        测试类中测试方法的顺序

        JUnit 不保证类中测试的执行顺序。大多数时候,在大多数 JVM 版本 7 之前,使用反射找到它们的顺序是声明顺序,即它们在文件中的顺序。这是它们的执行顺序。但是,对于 JVM 7,这不再得到保证,因此不会有一致的顺序。有一个 github 问题 #293 Sort test methods for predictability open with建议的解决方案,并且 junit 邮件列表上有一个线程:Alphabetizing test method run order?。因此,您不能依赖于使用 JUnit 执行测试的顺序,但这目前正在讨论中。

        【讨论】:

        • 所以我从这里认为测试应该能够独立执行,而不是取决于它们在@Suite 中的排列顺序。当我并行执行测试时,这会给我带来惊喜。对吗?
        • 测试方法(以及类)应该始终可以独立执行,前提是您可以在 IDE 中执行单个测试。这取决于您的并行运行程序如何执行测试,它是并行执行类还是并行执行类中的方法,但是是的,它可能会导致问题。最好尽量避免测试之间的所有依赖关系。
        • Matthew:只有单元测试应该是独立的。对于功能测试,能够专门为方法排序非常有用,这就是为什么它从版本 1 开始就成为 TestNG 的一个特性。
        【解决方案4】:

        只需在类名前使用 _# 对类名进行排序即可绕过它。前任 _1testcaselogin _2testcaseverify

        【讨论】:

          【解决方案5】:

          @jeha 答案非常好,但他谈到了测试方法(用@Test 注释的方法)顺序。这个顺序确实是未指定的,可能是因为反射得到的类中的方法顺序并不能保证与源文件中的方法顺序一致。

          但是根据我的经验,它们的执行顺序与大多数情况下定义的顺序相同。

          您在询问测试课程的顺序。这应该不足为奇:您正在使用@Suite.SuiteClasses 明确列出测试类,而JUnit 可能没有对它们进行改组和以不同顺序运行的业务。您是否担心仅仅因为您明确订购测试而在测试之间引入依赖关系?

          【讨论】:

          • 是的,我担心在执行 \@Suite 中指定的测试类时引入的排序。我觉得这是对 \@Suite 的滥用,如果我愿意,我不能只在 @Suite 之外执行“EditProfile.class”。
          【解决方案6】:

          不,不支持订购。是的,这是意图:

          KentBeck commented (December 30, 2010): 独立测试更有价值,因此 JUnit 设计不支持测试排序。

          如果你需要这个功能,你可以使用 TestNG,它是@Test(sequential = true)

          【讨论】:

          • 好吧,每次我执行它时,我都会看到首先调用 CreateNewProfile.class 的方法,然后是 EditProfile.class。现在不是下单了吗?
          • @Tarun:我猜这是实现方式的结果(隐式排序)。关键是不能保证执行顺序(没有明确的顺序),所以这可能会改变,你不能依赖它。
          • 使用 \@Suite 来订购测试类让我担心,因为当我在 \@suite 之外执行它们时,我无法独立执行它们
          • 实际上,对于 TestNG,它是 @Test(dependsOnMethods=...) 或者推荐的 @Test(dependsOnGroups=...)。
          • 可以在 JUnit 中使用类注释 @FixMethodOrder(MethodSorters.NAME_ASCENDING)(自 JUnit 4.11 起)实现排序,但由于已经提到的原因,应避免使用。
          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2018-04-11
          • 1970-01-01
          • 1970-01-01
          • 2011-09-30
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多