写单元测试的时候，很多人都会遇到这样的场景：一个方法需要验证几十种输入情况，如果每种输入都单独写一个测试方法，类文件会迅速膨胀到几百行，而且这些方法的逻辑几乎一模一样，复制粘贴改个参数就完事。JUnit 5 的参数化测试机制正是为这种场景而生的，它允许我们把测试数据抽离到集合、流或注解属性中，让同一个测试方法反复执行，每次消费一组数据。这篇文章就来详细讲讲如何用集合变量驱动多维度的测试用例。
一、参数化测试的基本原理与快速上手
参数化测试的核心思想是数据与逻辑分离。被@ParameterizedTest标注的测试方法不再是执行一次，而是由数据源决定执行多少次。每一条数据会被当作参数传入方法体，IDE 或测试报告中每一次执行都会显示为一个独立的测试节点，失败时能精确定位到是哪一组数据出了问题。
最简单的数据源是@ValueSource，它支持基本类型的数组。比如要验证一个判断字符串是否为空白的方法，可以这样写：
@ParameterizedTest
@ValueSource(strings = {"", " ", "\t", "\n"})
void testIsBlank(String input) {
assertTrue(StringUtil.isBlank(input));
}这段代码实际上会产生四次测试执行，分别对应四个字符串。注意"\t"和"\n"里的反斜杠是转义符，代表制表符和换行符，JUnit 会按字面语义处理它们。
除了@ValueSource，@EnumSource可以直接遍历枚举的所有实例，@NullAndEmptySource、@NullSource、@EmptySource则专门补充空值和空集合场景。这些注解可以叠加使用，组合出更完整的边界覆盖。
二、用 MethodSource 配合集合变量构建多维度数据
真实业务中的测试数据往往不止一个维度。比如验证一个计算运费的方法，输入包括重量、目的地类型、是否加急三个维度，靠单值注解无法表达。这时@MethodSource配合集合变量就是最灵活的方案。
@MethodSource指向一个静态工厂方法，该方法返回Stream<Arguments>、Collection<Arguments>或者List等容器，JUnit 会把每一组返回值作为参数传给测试方法。来看一个实际例子：
@ParameterizedTest
@MethodSource("provideShippingCases")
void testCalcShippingFee(double weight, Region region, boolean urgent, double expected) {
double actual = ShippingCalculator.calc(weight, region, urgent);
assertEquals(expected, actual, 0.001);
}
static Stream<Arguments> provideShippingCases() {
List<Arguments> cases = new ArrayList<>();
cases.add(Arguments.of(1.0, Region.DOMESTIC, false, 8.0));
cases.add(Arguments.of(5.5, Region.DOMESTIC, true, 23.0));
cases.add(Arguments.of(2.0, Region.OVERSEAS, false, 40.0));
cases.add(Arguments.of(10.0, Region.OVERSEAS, true, 95.0));
return cases.stream();
}这种写法的最大好处是数据可以动态构造。如果测试数据本身来自外部配置或者数据库查询，只需要在工厂方法里把结果装配成集合即可，测试方法完全不用改动。另外，工厂方法返回Stream时支持惰性求值，数据量特别大的时候不会一次性把所有对象都加载到内存中。
需要注意的是，JUnit 5.3 之后如果没有同名方法冲突，@MethodSource可以省略方法名，默认查找与测试方法同名的静态方法。如果想用非静态方法，需要给测试类加上@TestInstance(TestInstance.Lifecycle.PER_CLASS)注解。
当维度特别多、参数列表很长时，方法签名会变得难以阅读。此时可以借助@CsvSource以类似表格的方式声明数据，或者用ArgumentsAccessor做参数聚合：
@ParameterizedTest
@MethodSource("provideOrderCases")
void testOrder(ArgumentsAccessor args) {
int quantity = args.getInteger(0);
double unitPrice = args.getDouble(1);
boolean vip = args.getBoolean(2);
double expected = args.getDouble(3);
assertEquals(expected, OrderService.total(quantity, unitPrice, vip), 0.001);
}更进一步，还可以自定义一个实现ArgumentsAggregator的聚合类，配合@AggregateWith注解把多个参数直接组装成业务对象，测试方法的签名就只剩一个领域模型参数，可读性大幅提升。
三、常见坑点与最佳实践
第一个常见的坑是生命周期问题。@MethodSource的工厂方法默认必须是静态的，新手经常写成实例方法导致PreconditionViolationException。如果确实需要访问实例状态，务必配合生命周期注解修改，而不是简单去掉 static 就完事。
第二个坑是数据源冲突。同一个测试方法上如果同时出现多个数据源注解，比如既加了@ValueSource又加了@MethodSource，JUnit 启动时会直接报错。数据源注解只能选一个，但@NullSource这类补充型注解可以与主数据源叠加。
第三个坑是断言失败时的定位效率。默认报告里参数化测试的显示名只是参数序号，排查问题时很不直观。建议养成给用例命名的习惯：
@ParameterizedTest(name = "[{index}] weight={0}, region={1}, urgent={2} => {3}")
@MethodSource("provideShippingCases")
void testCalcShippingFee(double weight, Region region, boolean urgent, double expected) {
// 测试逻辑
}这样测试报告中每一行都会显示具体输入，一眼就能看出是哪组数据挂了。
最后给几条实践建议：测试数据量要适度，一次参数化跑上千组数据会拖慢构建速度，边界值、等价类、典型异常输入优先；对于复杂对象参数，优先使用工厂方法而不是序列化成 CSV 字符串，避免引号转义带来的隐性 bug；如果多个测试类共用同一批数据，可以把工厂方法抽到独立的工具类中，通过@MethodSource("com.example.TestData#provideCases")的全限定名引用，实现测试数据复用。
总结一下，参数化测试把重复的测试逻辑压缩成一份代码，把变化的测试数据集中到集合或流中管理，无论是可读性还是可维护性都有质的提升。掌握@MethodSource配合List、Stream构造多维数据的方式，再辅以自定义命名和参数聚合技巧，就能轻松应对绝大多数数据驱动的测试场景。