使用 JUnit 5.7 进行参数化测试：深入了解 @EnumSource

使用 JUnit 5.7 进行参数化测试：深入了解 @EnumSource    

     参数化测试允许开发人员使用一系列输入值高效地测试他们的代码。在 JUnit 测试领域，经验丰富的用户长期以来一直在努力解决实施这些测试的复杂问题。但随着 JUnit 5.7 的发布，测试参数化进入了一个新时代，为开发人员提供了一流的支持和增强的功能。让我们深入探讨 JUnit 5.7 为参数化测试带来的激动人心的可能性！

JUnit 5.7 文档中的参数化示例 让我们看看文档中的一些示例：

@ParameterizedTest
@ValueSource(strings = { "racecar", "radar", "able was I ere I saw elba" })
void palindromes(String candidate) {
     assertTrue(StringUtils.isPalindrome(candidate));
}

@ParameterizedTest
@CsvSource({
     "apple,         1",
     "banana,        2",
     "'lemon, lime', 0xF1",
     "strawberry,    700_000"
})

void testWithCsvSource(String fruit, int rank) {
     assertNotNull(fruit);
     assertNotEquals(0, rank);
}

@ParameterizedTest
@MethodSource("stringIntAndListProvider")
void testWithMultiArgMethodSource(String str, int num, List<String> list) {
     assertEquals(5, str.length());
     assertTrue(num >=1 && num <=2);
     assertEquals(2, list.size());
}

static Stream<Arguments> stringIntAndListProvider() {
     return Stream.of(
         arguments("apple", 1, Arrays.asList("a", "b")),
         arguments("lemon", 2, Arrays.asList("x", "y"))
     );
}

在使用 @ParameterizedTest 注解的同时，还必须使用所提供的几个源注解之一，说明从何处获取参数。参数来源通常被称为 "数据提供者"。

@RunWith(JUnit4.class)
@SpringBootTest
public class MyTest {

    @ParameterizedTest
     @ValueSource(ints = {1, 2, 3})
     public void testWithIntValue(int value) {
         // ...
     }

}

在此，我将不对其进行详细描述：JUnit 用户指南比我做得更好，但请允许我分享几点看法：

@ValueSource 只限于提供单个参数值。换句话说，测试方法不能有一个以上的参数，而且可以使用的类型也受到限制。
@CsvSource 在一定程度上解决了传递多个参数的问题，它将每个字符串解析为一条记录，然后作为参数逐字段传递。对于长字符串和/或大量参数，这很容易造成阅读困难。此外，可以使用的类型也受到了限制--稍后再详述。
在注解中声明实际值的所有来源都被限制为编译时常量（Java 注释的限制，而非 JUnit）。
@MethodSource 和 @ArgumentsSource 提供了（无类型的）n 个元组的流/集合，这些元组将作为方法参数传递。我们支持各种实际类型来表示 n 个元组的序列，但它们都不能保证符合方法的参数列表。这种源需要额外的方法或类，但对从哪里和如何获取测试数据没有限制。

正如您所看到的，可用的源类型从简单类型（使用简单，但功能有限）到最终需要更多代码才能运行的灵活类型不等。

Sidenote --这通常是良好设计的标志：只需少量代码就能实现基本功能，而当用于实现要求更高的用例时，增加额外的复杂性是合理的。 @EnumSource 似乎并不符合这种从简单到灵活的连续性假设。请看这个包含四个参数集的非复杂示例，每个参数集有两个值。

Note --虽然 @EnumSource 将枚举的值作为单个测试方法参数传递，但从概念上讲，测试是由枚举字段参数化的，因此对参数数量没有限制。

    enum Direction {
         UP(0, '^'),
         RIGHT(90, '>'),
         DOWN(180, 'v'),
         LEFT(270, '<');

        private final int degrees;
         private final char ch;

        Direction(int degrees, char ch) {
             this.degrees = degrees;
             this.ch = ch;
         }
     }

    @ParameterizedTest
     @EnumSource
     void direction(Direction dir) {
         assertEquals(0, dir.degrees % 90);
         assertFalse(Character.isWhitespace(dir.ch));
        
         int orientation = player.getOrientation();
         player.turn(dir);
         assertEquals((orientation + dir.degrees) % 360, player.getOrientation());
     }

试想一下：硬编码的值列表严重限制了它的灵活性（不能使用外部数据或生成数据），而声明枚举所需的额外代码量又使它比 @CsvSource 更为冗长。

但这只是第一印象。我们将看到，当利用 Java 枚举的真正威力时，它会变得多么优雅。

附注：本文不涉及验证生产代码中的枚举。当然，无论您选择何种验证方式，都必须声明这些枚举。本文的重点是何时以及如何以枚举的形式表达测试数据。

何时使用
在某些情况下，枚举的性能比其他方法更好：

每次测试多个参数
       当您只需要一个参数时，您可能不想让 @ValueSource 以外的事情变得复杂。但一旦您需要多个参数，例如输入和预期结果，您就必须使用 @CsvSource、@MethodSource/@ArgumentsSource 或 @EnumSource。

在某种程度上，枚举可以让你 "偷渡 "任意数量的数据字段。

因此，当您将来需要添加更多测试方法参数时，只需在现有的枚举中添加更多的字段，而无需触动测试方法签名。当你在多个测试中重复使用数据提供者时，这一点就变得非常重要。

对于其他数据源，必须使用 ArgumentsAccessors 或 ArgumentsAggregators 才能获得枚举开箱即用的灵活性。

类型安全
对于 Java 开发人员来说，这应该是一个大问题。

从 CSV（文件或字面）、@MethodSource 或 @ArgumentsSource 读取的参数无法在编译时保证参数数量及其类型与签名相匹配。

显然，JUnit 会在运行时发出抱怨，但 IDE 不会提供任何代码帮助。

和以前一样，当你在多个测试中重复使用相同的参数时，这种情况就会增加。在将来扩展参数集时，使用类型安全的方法将大有裨益。

自定义类型
对于基于文本的数据源（如从 CSV 读取数据的数据源）来说，这主要是一个优势--文本中编码的值需要转换为 Java 类型。

如果要从 CSV 记录中实例化一个自定义类，可以使用 ArgumentsAggregator 来实现。但是，您的数据声明仍然不是类型安全的--方法签名和声明数据之间的任何不匹配都会在运行时 "聚合 "参数时弹出。更不用说，声明聚合器类会增加参数化工作所需的更多支持代码。为了避免额外的代码，我们更倾向于使用 @CsvSource 而不是 @EnumSource。

可文档化
      与其他方法不同，枚举源为参数集（枚举实例）及其包含的所有参数（枚举字段）都提供了 Java 符号。它们为以 JavaDoc 这种更自然的形式附加文档提供了一个直接的位置。

文档并非不能放置在其他地方，但顾名思义，它将被放置在离文档更远的地方，因此更难找到，也更容易过时。

但还有更多枚举。是类。

许多初级开发人员还没有意识到 Java 枚举的真正强大之处。

在其他编程语言中，枚举只是美化了的常量。但在 Java 中，它们是 Flyweight 设计模式的便捷小实现，具有完整类的（大部分）优点。

为什么这是件好事呢？

测试与夹具相关的行为

     与其他任何类一样，枚举可以添加方法。如果枚举测试参数在不同测试间重复使用，这就变得非常方便--相同的数据，只是测试方式略有不同。为了在不进行大量复制和粘贴的情况下有效使用参数，这些测试之间还需要共享一些辅助代码。这不是一个辅助类和几个静态方法所能 "解决 "的。附注：请注意，这样的设计会让人产生 "功能嫉妒"（Feature Envy）。测试方法--或者更糟糕的是，辅助类方法--必须从枚举对象中提取数据，才能对这些数据执行操作。虽然这是过程式编程的（唯一）方法，但在面向对象的世界里，我们可以做得更好。 在枚举声明中直接声明 "辅助 "方法，我们就可以把代码移到数据所在的地方。或者，用 OOP 术语来说，辅助方法将成为以枚举形式实现的测试夹具的 "行为"。这不仅会使代码更加习以为常（在实例上调用合理的方法而不是传递数据的静态方法），而且还能使枚举参数在测试用例中更容易地重复使用。

继承
枚举可以实现带有（默认）方法的接口。在合理使用的情况下，可以利用这一点在多个数据提供者（多个枚举）之间共享行为。我很容易想到的一个例子就是为正向测试和负向测试分别建立枚举。如果它们代表了类似的测试夹具，那么它们就有可能共享某些行为。

Talk is cheap空谈误国

     让我们用一个假设的源代码文件转换器测试套件来说明这一点，它与执行 Python 2 到 Python 3 转换的测试套件不太一样。要想对这样一个综合工具的工作有真正的信心，我们最终需要大量的输入文件，这些文件体现了语言的各个方面，还需要匹配文件来比较转换结果。除此之外，还需要验证有问题的输入会向用户发出哪些警告/错误。 由于需要验证的样本数量庞大，这自然适合参数化测试，但由于数据有些复杂，它不太适合任何简单的 JUnit 参数源。

   enum Conversion {
         CLEAN("imports-correct.2.py", "imports-correct.3.py", Set.of()),
         WARNINGS("problematic.2.py", "problematic.3.py", Set.of(
                 "Using module 'xyz' that is deprecated"
         )),
         SYNTAX_ERROR("syntax-error.py", new RuntimeException("Syntax error on line 17"));
         // Many, many others ...

        @Nonnull
         final String inFile;
         @CheckForNull
         final String expectedOutput;
         @CheckForNull
         final Exception expectedException;
         @Nonnull
         final Set<String> expectedWarnings;

        Conversion(@Nonnull String inFile, @Nonnull String expectedOutput, @NotNull Set<String> expectedWarnings) {
             this(inFile, expectedOutput, null, expectedWarnings);
         }

        Conversion(@Nonnull String inFile, @Nonnull Exception expectedException) {
             this(inFile, null, expectedException, Set.of());
         }

        Conversion(@Nonnull String inFile, String expectedOutput, Exception expectedException, @Nonnull Set<String> expectedWarnings) {
             this.inFile = inFile;
             this.expectedOutput = expectedOutput;
             this.expectedException = expectedException;
             this.expectedWarnings = expectedWarnings;
         }

        public File getV2File() { ... }

        public File getV3File() { ... }
     }

    @ParameterizedTest
     @EnumSource
     void upgrade(Conversion con) {

        try {
             File actual = convert(con.getV2File());
             if (con.expectedException != null) {
                 fail("No exception thrown when one was expected", con.expectedException);
             }
             assertEquals(con.expectedWarnings, getLoggedWarnings());
             new FileAssert(actual).isEqualTo(con.getV3File());
         } catch (Exception ex) {
             assertTypeAndMessageEquals(con.expectedException, ex);
         }
     }

使用枚举并不会限制数据的复杂程度。正如你所看到的，我们可以在枚举中定义几个方便的构造函数，因此声明新的参数集非常简洁。这就避免了使用长参数列表的情况，因为长参数列表中往往充满了许多 "空 "值（空值、空字符串或集合），让人不知道 7 号参数--也就是空值之一--究竟代表什么。请注意，枚举允许使用复杂类型（Set、RuntimeException），而没有任何限制或神奇的转换。传递此类数据也是完全类型安全的。实际上，你将有更多的数据样本需要验证，因此模板代码的数量相比之下就不那么重要了。

此外，还可以看看如何利用相同的枚举及其辅助方法编写相关测试：

    @ParameterizedTest
     @EnumSource
     // Upgrading files already upgraded always passes, makes no changes, issues no warnings.
     void upgradeFromV3toV3AlwaysPasses(Conversion con) throws Exception {
         File actual = convert(con.getV3File());
         assertEquals(Set.of(), getLoggedWarnings());
         new FileAssert(actual).isEqualTo(con.getV3File());
     }

    @ParameterizedTest
     @EnumSource
     // Downgrading files created by upgrade procedure is expected to always pass without warnings.
     void downgrade(Conversion con) throws Exception {
         File actual = convert(con.getV3File());
         assertEquals(Set.of(), getLoggedWarnings());
         new FileAssert(actual).isEqualTo(con.getV2File());
     }

    多说几句 从概念上讲，@EnumSource 鼓励您创建复杂的、机器可读的单个测试场景描述，模糊了数据提供程序和测试夹具之间的界限。将每个数据集表示为 Java 符号（枚举元素）的另一个好处是，它们可以单独使用，完全脱离数据提供程序/参数化测试。由于它们有一个合理的名称，而且自成一体（在数据和行为方面），因此它们有助于形成漂亮和可读的测试。

@Test
void warnWhenNoEventsReported() throws Exception {
     FixtureXmls.Invalid events = FixtureXmls.Invalid.NO_EVENTS_REPORTED;
    
     // read() is a helper method that is shared by all FixtureXmls
     try (InputStream is = events.read()) {
         EventList el = consume(is);
         assertEquals(Set.of(...), el.getWarnings());
     }
}

现在，@EnumSource 不会成为你最常用的参数源之一，这是好事，因为过度使用它不会有任何好处。但在适当的情况下，知道如何使用它们所提供的一切，还是很方便的。

如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：

作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。