Add List-based support to Arguments API #4574

mariokhoury4 · 2025-05-24T22:39:31Z

Overview

This PR adds List-based support to the Arguments API for parameterized tests.

New additions:

Arguments.of(List<@Nullable Object>)
Arguments.arguments(List<@Nullable Object>) (alias)
Arguments.argumentSet(String, List<@Nullable Object>)
Arguments.toList() — returns a mutable List<@Nullable Object>

These additions make it easier to dynamically build arguments from collections when using @ParameterizedTest.

All additions are tested in ArgumentsTests.java.

Fixes #4535

I hereby agree to the terms of the JUnit Contributor License Agreement.

Definition of Done

There are no TODOs left in the code
Method preconditions are checked and documented in the method's Javadoc
Coding conventions (e.g. for logging) have been followed
Change is covered by automated tests including corner cases, errors, and exception handling
Public API has Javadoc and @API annotations
Change is documented in the User Guide and Release Notes

…toList)

marcphilipp · 2025-05-25T11:21:51Z

junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/Arguments.java

+	static Arguments of(@Nullable List<@Nullable Object> arguments) {
+		if (arguments == null) {
+			return of((Object) null); // Properly wrap null
+		}


Suggested change

static Arguments of(@Nullable List<@Nullable Object> arguments) {

if (arguments == null) {

return of((Object) null); // Properly wrap null

}

static Arguments of(List<@Nullable Object> arguments) {

Preconditions.notNull(arguments, "arguments must not be null");

marcphilipp · 2025-05-25T11:22:51Z

junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/Arguments.java

+		if (arguments.isEmpty()) {
+			// Must still return empty arguments array
+			return of(new Object[0]);
+		}
+		return () -> arguments.toArray(new Object[0]);


Suggested change

if (arguments.isEmpty()) {

// Must still return empty arguments array

return of(new Object[0]);

}

return () -> arguments.toArray(new Object[0]);

return of(arguments.toArray());

marcphilipp · 2025-05-25T11:23:21Z

junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/Arguments.java

+	static ArgumentSet argumentSet(String name, List<@Nullable Object> arguments) {
+		Preconditions.notBlank(name, "name must not be null or blank");
+		Preconditions.notNull(arguments, "arguments list must not be null");
+		return new ArgumentSet(name, arguments.toArray(new Object[0]));


Suggested change

return new ArgumentSet(name, arguments.toArray(new Object[0]));

return new ArgumentSet(name, arguments.toArray());

marcphilipp · 2025-05-25T11:26:43Z

...t-jupiter-params/src/main/java/org/junit/jupiter/params/provider/EmptyArgumentsProvider.java

-			return Stream.of(arguments(Collections.emptyList()));
+			return Stream.of(Arguments.of((Object) Collections.emptyList()));


This makes me wonder whether we should choose different names instead of overloading of(), arguments(), and argumentSet() to avoid such breakages. Maybe copyOf, argumentsOf, and argumentSetOf()?

@junit-team/junit-5 WDYT?

Well, we unfortunately overlooked the fact that a single List is also a single Object, so we definitely cannot go with this as-is.

Existing code must still compile without adding casts.

Though, in our defense, it is easy to overlook something like that when "coding in the browser". 😉

Maybe copyOf, argumentsOf, and argumentSetOf()?

I would rather go with something consistent, instead of having "copy" in only one of the names.

How about something like fromList(), argumentsFromList(), and argumentSetFromList()?

We could also drop the List part of the names, if we are somehow sure we will never introduce yet-another-set-of-overloads. So, something like from(), argumentsFrom(), and argumentSetFrom().

Thoughts?

Thanks for the thoughtful feedback! I agree that it's important to avoid breaking existing usage. I also like the idea of going with a more general naming convention, so my preference would be to use from() instead of fromList() or argumentsFrom(). I'm happy to update the PR accordingly once there's consensus.

+1 on the shorter variants. We might even get away with adding overloads to that in the future because "conflicts" with List seem less likely than with Object...

I have updated the code with the suggestions!

I'd pondered it more while away from the computer and decided that I'm in favor of the from(), argumentsFrom() and argumentSetFrom() variants because of the brevity and also because of the nice symmetry with the new toList() instance method.

from(List) and toList() work well together.

So, I'm glad to see you both agree and that you're already implemented the changes, @mariokhoury4. 👍

marcphilipp · 2025-05-25T11:27:18Z

junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/Arguments.java

@@ -172,4 +176,72 @@ public String toString() {

 	}

+	/**


Please move these next to the other static factory methods above.

Thanks for the suggestion! I'll move the method next to the other static factory methods to keep things consistent.

…est accordingly

marcphilipp · 2025-05-26T06:36:24Z

junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/Arguments.java

@@ -125,6 +129,77 @@ static ArgumentSet argumentSet(String name, @Nullable Object... arguments) {
 		return new ArgumentSet(name, arguments);
 	}

+	/**
+	 * Factory method for creating an instance of {@code Arguments} based on
+	 * the supplied {@code arguments} as a {@link List}.


Suggested change

* the supplied {@code arguments} as a {@link List}.

* the supplied {@link List} of {@code arguments}.

(same below for other methods)

marcphilipp · 2025-05-26T06:37:01Z

junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/Arguments.java

+	 * @param arguments the arguments as a List to be used for an invocation
+	 * of the test method; must not be {@code null} but may contain {@code null}


Suggested change

* @param arguments the arguments as a List to be used for an invocation

* of the test method; must not be {@code null} but may contain {@code null}

* @param arguments the arguments to be used for an invocation of the test

* method; must not be {@code null} but may contain {@code null}

(same below for other methods)

marcphilipp · 2025-05-26T06:38:32Z

junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/Arguments.java

+	 * Convert the arguments to a new mutable {@link List} containing the same
+	 * elements as {@link #get()}.
+	 *
+	 * <p>This is useful for test logic that benefits from {@code List} operations such as filtering,


Please hard-wrap lines at 80 chars.

marcphilipp · 2025-05-26T06:38:53Z

jupiter-tests/src/test/java/org/junit/jupiter/params/provider/ArgumentsTests.java

@@ -56,4 +60,50 @@ void argumentsReturnsSameArrayUsedForCreating() {
 		assertThat(arguments.get()).isSameAs(input);
 	}

+	@Test
+	void ofSupportsList() {


Suggested change

void ofSupportsList() {

void fromSupportsList() {

marcphilipp · 2025-05-26T06:39:37Z

jupiter-tests/src/test/java/org/junit/jupiter/params/provider/ArgumentsTests.java

+	}
+
+	@Test
+	void argumentsSupportsListAlias() {


Suggested change

void argumentsSupportsListAlias() {

void argumentsFromSupportsList() {

marcphilipp · 2025-05-26T06:40:08Z

jupiter-tests/src/test/java/org/junit/jupiter/params/provider/ArgumentsTests.java

+
+		assertThat(result).containsExactly("a", 2, null); // preserves content
+		result.add("extra"); // confirms mutability
+		assertThat(result).contains("extra");


Please also verify that the array in arguments can't be modified.

marcphilipp · 2025-05-26T06:40:25Z

jupiter-tests/src/test/java/org/junit/jupiter/params/provider/ArgumentsTests.java

+
+	@Test
+	void toListWorksOnEmptyArguments() {
+		Arguments arguments = Arguments.from(Arrays.asList());


Suggested change

Arguments arguments = Arguments.from(Arrays.asList());

Arguments arguments = Arguments.of();

marcphilipp · 2025-05-26T06:40:44Z

jupiter-tests/src/test/java/org/junit/jupiter/params/provider/ArgumentsTests.java

+
+	@Test
+	void toListReturnsMutableListOfArguments() {
+		Arguments arguments = Arguments.from(Arrays.asList("a", 2, null));


Suggested change

Arguments arguments = Arguments.from(Arrays.asList("a", 2, null));

Arguments arguments = Arguments.of("a", 2, null);

marcphilipp · 2025-05-26T06:41:16Z

jupiter-tests/src/test/java/org/junit/jupiter/params/provider/ArgumentsTests.java

+		List<Object> input = Arrays.asList(1, "two", null, 3.0);
+		Arguments arguments = Arguments.from(input);
+
+		assertArrayEquals(new Object[] { 1, "two", null, 3.0 }, arguments.get());


Please add an assertion verifying that modifying the initial List has no effect on arguments

sbrannen · 2025-05-28T11:14:33Z

junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/Arguments.java

+	 * @param arguments the arguments to be used for an invocation of the test
+	 * method; must not be {@code null} but may contain {@code null}.
+	 * @return an instance of {@code Arguments}; never {@code null}.
+	 * @since 6.0


Suggested change

* @param arguments the arguments to be used for an invocation of the test

* method; must not be {@code null} but may contain {@code null}.

* @return an instance of {@code Arguments}; never {@code null}.

* @since 6.0

* @param arguments the arguments to be used for an invocation of the test

* method; must not be {@code null} but may contain {@code null}

* @return an instance of {@code Arguments}; never {@code null}

* @since 6.0

sbrannen · 2025-05-28T11:14:48Z

junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/Arguments.java

+	 * @param arguments the arguments to be used for an invocation of the test
+	 * method; must not be {@code null} but may contain {@code null}.
+	 * @return an instance of {@code Arguments}; never {@code null}.


Suggested change

* @param arguments the arguments to be used for an invocation of the test

* method; must not be {@code null} but may contain {@code null}.

* @return an instance of {@code Arguments}; never {@code null}.

* @param arguments the arguments to be used for an invocation of the test

* method; must not be {@code null} but may contain {@code null}

* @return an instance of {@code Arguments}; never {@code null}

sbrannen · 2025-05-28T11:15:09Z

junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/Arguments.java

+	 * @param name the name of the argument set; must not be {@code null}
+	 * or blank.
+	 * @param arguments the arguments to be used for an invocation of the test
+	 * method; must not be {@code null} but may contain {@code null}.
+	 * @return an {@code ArgumentSet}; never {@code null}.


Suggested change

* @param name the name of the argument set; must not be {@code null}

* or blank.

* @param arguments the arguments to be used for an invocation of the test

* method; must not be {@code null} but may contain {@code null}.

* @return an {@code ArgumentSet}; never {@code null}.

* @param name the name of the argument set; must not be {@code null}

* or blank

* @param arguments the arguments to be used for an invocation of the test

* method; must not be {@code null} but may contain {@code null}

* @return an {@code ArgumentSet}; never {@code null}

sbrannen · 2025-05-28T11:15:52Z

junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/Arguments.java

+	 * @return a mutable List of arguments; never {@code null} but may contain
+	 * {@code null}.


Suggested change

* @return a mutable List of arguments; never {@code null} but may contain

* {@code null}.

* @return a mutable List of arguments; never {@code null} but may contain

* {@code null}

vlsi

Just wondering: have you considered Iterable<? extends @Nullable Object> rather than using a plain List?

Based on my experience with checkerframework's @Nullable, I would suggest List<? extends @Nullable Object> rather than List<Object>.

I've asked jspecify to clarify the documentation anyways: jspecify/jspecify#748

At the same time, it would be nice to add tests that pass something like List<String> to the newly added methods.

For instance, from(Files.readAllLines("path")). I guess the code won't compile if the method uses List<Object> signatures.

vlsi · 2025-06-05T12:41:42Z

junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/Arguments.java

+	 * @see #argumentsFrom(List)
+	 */
+	@API(status = EXPERIMENTAL, since = "6.0")
+	static Arguments from(List<@Nullable Object> arguments) {


Should this use generic variance?
Otherwise users would not be able to pass a list with non-nullable values.

Suggested change

static Arguments from(List<@Nullable Object> arguments) {

static Arguments from(List<?> arguments) {

vlsi · 2025-06-05T12:42:58Z

junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/Arguments.java

+	 * @see #argumentSet(String, Object...)
+	 */
+	@API(status = EXPERIMENTAL, since = "6.0")
+	static Arguments argumentsFrom(List<@Nullable Object> arguments) {


Suggested change

static Arguments argumentsFrom(List<@Nullable Object> arguments) {

static Arguments argumentsFrom(List<?> arguments) {

vlsi · 2025-06-05T13:23:38Z

One more thing: List<?> is a good enough replacement for List<? extends @Nullable Object>. In this case, the method should probably have a signature like from(Iterable<?>)

marcphilipp · 2025-06-05T15:13:23Z

One more thing: List<?> is a good enough replacement for List<? extends @Nullable Object>

I didn't know that but sounds like you're right, according to the spec:

If an unbounded wildcard appears in a null-marked scope, then it has a single upper bound whose base type is Object and whose nullness operator is UNION_NULL.

Therefore, I think using List<?> as method parameter and return type of toList() makes sense.

Just wondering: have you considered Iterable rather than using a plain List?

The use case we're addressing here is constructing new Arguments instances from existing ones so I don't think that flexibility is needed. Moreover, we could introduce it later, if necessary.

vlsi · 2025-06-05T15:46:38Z

junit-jupiter-params/src/main/java/org/junit/jupiter/params/provider/Arguments.java

+	 * @param arguments the arguments to be used for an invocation of the test
+	 * method; must not be {@code null} but may contain {@code null}.
+	 * @return an instance of {@code Arguments}; never {@code null}.


Is It really worth documenting never {@code null}.? I'm afraid it adds excessive verbosity.

I think the best practice is non-null by default, so WDYT of documenting only the places where nulls can appear rather than trying to document every possible case?

Suggested change

* @param arguments the arguments to be used for an invocation of the test

* method; must not be {@code null} but may contain {@code null}.

* @return an instance of {@code Arguments}; never {@code null}.

* @param arguments the arguments to be used for an invocation of the test

* method; it may contain {@code null} elements.

* @return an instance of {@code Arguments}

It may be excessive but clear. Moreover, we'd have to change that throughout the entire code base.

vlsi · 2025-06-05T15:48:46Z

@marcphilipp , sorry for asking the same thing twice, however, could you please clarify why do you mean Arguments.from(List), Arguments argumentsFrom(List), and ArgumentSet argumentSetFrom(String name, List) relate to "from existing ones"?

To me the second case of #4535 sounds like a natural case for using argumentsFrom(Iterable<?>) rather than a pure List.

An Arguments can only be created from an array, not a collection.

I've no issues if Arguments.toList returns List. However, I believe on the consumption side, Arguments.from should accept Iterable so the users could supply various types of collections they have.

Of course, it would be great if Java had something like IterableWithPredefinedIterationOrder, so users don't accidentally pass HashSet and get their arguments shuffled.

If you mean you force List so the users do not supply collections like Stream...parallel()... and somehow complain "the order of arguments is wrong sometimes"? If that is the case, it is probably worth documenting as "this List<?> could have been Iterable<?>" is a typical code review case.

marcphilipp · 2025-06-06T14:25:05Z

sorry for asking the same thing twice, however, could you please clarify why do you mean Arguments.from(List), Arguments argumentsFrom(List), and ArgumentSet argumentSetFrom(String name, List) relate to "from existing ones"?

The use case we're trying to address here is to go from an existing Arguments instance to a new one without re-inventing a new collection API.

I've no issues if Arguments.toList returns List. However, I believe on the consumption side, Arguments.from should accept Iterable so the users could supply various types of collections they have.

We'll discuss that in one of our next team calls.

mariokhoury4 force-pushed the arguments-list-support branch 4 times, most recently from 3a32cf8 to 9de99b7 Compare May 24, 2025 23:43

Add List-based support to Arguments API (of, arguments, argumentSet, …

3f3aa29

…toList)

mariokhoury4 force-pushed the arguments-list-support branch from 9de99b7 to 3f3aa29 Compare May 24, 2025 23:47

marcphilipp requested changes May 25, 2025

View reviewed changes

mariokhoury4 force-pushed the arguments-list-support branch from cbde5ed to a2ca294 Compare May 25, 2025 15:45

Address feedback: fix argumentsFrom to unpack List properly, update t…

d566f95

…est accordingly

mariokhoury4 force-pushed the arguments-list-support branch from a2ca294 to d566f95 Compare May 25, 2025 15:50

marcphilipp requested changes May 26, 2025

View reviewed changes

mariokhoury4 and others added 2 commits May 27, 2025 21:49

Address feedback: fix documentation and adding test cases

b73ae11

Merge branch 'main' into arguments-list-support

87ca6b4

sbrannen requested changes May 28, 2025

View reviewed changes

vlsi reviewed Jun 5, 2025

View reviewed changes

	return new ArgumentSet(name, arguments.toArray(new Object[0]));
	return new ArgumentSet(name, arguments.toArray());

		return Stream.of(arguments(Collections.emptyList()));
		return Stream.of(Arguments.of((Object) Collections.emptyList()));

	* the supplied {@code arguments} as a {@link List}.
	* the supplied {@link List} of {@code arguments}.

		* @param arguments the arguments as a List to be used for an invocation
		* of the test method; must not be {@code null} but may contain {@code null}

	void argumentsSupportsListAlias() {
	void argumentsFromSupportsList() {

	Arguments arguments = Arguments.from(Arrays.asList());
	Arguments arguments = Arguments.of();

	Arguments arguments = Arguments.from(Arrays.asList("a", 2, null));
	Arguments arguments = Arguments.of("a", 2, null);

		* @return a mutable List of arguments; never {@code null} but may contain
		* {@code null}.

	static Arguments from(List<@Nullable Object> arguments) {
	static Arguments from(List<?> arguments) {

	static Arguments argumentsFrom(List<@Nullable Object> arguments) {
	static Arguments argumentsFrom(List<?> arguments) {

Uh oh!

Add List-based support to Arguments API #4574

Are you sure you want to change the base?

Add List-based support to Arguments API #4574

Uh oh!

Conversation

mariokhoury4 commented May 24, 2025

Overview

New additions:

Definition of Done

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sbrannen May 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vlsi left a comment

Choose a reason for hiding this comment

Uh oh!

vlsi Jun 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vlsi Jun 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vlsi commented Jun 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marcphilipp commented Jun 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

sbrannen May 25, 2025 •

edited

Loading

vlsi Jun 5, 2025 •

edited

Loading

vlsi Jun 5, 2025 •

edited

Loading

vlsi commented Jun 5, 2025 •

edited

Loading