Overloaded method accepting arguments clashes with intended @MethodSource factory method

[sbrannen]

Overview

As mentioned in #2191 (comment), prior to Jupiter 5.9 if an overloaded method that accepts arguments also met the criteria for a factory method (based on the return type), that method would not have been considered a factory method.

However, as of Jupiter 5.9 (including 5.9.1) such an overloaded method will be considered a candidate factory method. Consequently, if that method is an overload for the intended @MethodSource factory method an exception will be thrown stating that multiple competing factory methods were discovered.

Example

WorkingTests succeeds. FailingTests fails because it extends Base.

package example;

import java.util.stream.Stream;
import org.junit.jupiter.api.Nested;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.MethodSource;

import static org.junit.jupiter.api.Assertions.assertEquals;

class MethodSourceFactoryTests {

	@Nested
	class WorkingTests {

		@ParameterizedTest
		@MethodSource("data")
		void test(String value) {
			assertEquals(1, value.length());
		}

		// legitimate factory method.
		static Stream<String> data() {
			return Stream.of("a", "b");
		}
	}

	@Nested
	class FailingTests extends Base {

		@ParameterizedTest
		@MethodSource("data")
		void test(String value) {
			assertEquals(1, value.length());
		}

		// legitimate factory method.
		static Stream<String> data() {
			return Stream.of("a", "b");
		}
	}

	static class Base {

		// Jupiter 5.8: not considered a factory method.
		// Jupiter 5.9: considered a factory method.
		static Stream<String> data(String first) {
			return Stream.of(first);
		}
	}

}

Related Issues

• Use registered ParameterResolver(s) when invoking @MethodSource factory methods #2191
• ReflectionUtils.findMethods() returns duplicate methods, breaking certain use cases #2993
• Regression in @MethodSource factory method resolution #3001

Deliverables

• Determine if there are any improvements that can be made and otherwise document the status quo (including workarounds).

[sbrannen]

I believe I mentioned this elsewhere, but I'll restate it here...

The current workaround is to use the fully qualified method name to disambiguate between overloaded methods.

However, that is extremely verbose for a locally declared factory method.

For example, the failing test can be fixed with one of the following.

@MethodSource("example.MethodSourceFactoryTests$FailingTests#data")

or

@MethodSource("example.MethodSourceFactoryTests$FailingTests#data()")

To improve the developer experience, we could introduce a simplified syntax for selecting a local factory method (local to the current type hierarchy -- in other words not in an external class).

The following are examples of how this could look (omitting the fully qualified class name).

@MethodSource("data()")

or

@MethodSource("#data()")

---

In summary, the user originally had this:

@MethodSource("data")

... which leads to ambiguous factory method selection.

And I'm proposing that the user can switch to this for explicit local factory method selection.

@MethodSource("data()") // or @MethodSource("#data()")

@junit-team/junit-lambda, thoughts?

[marcphilipp]

SGTM 👍

[sbrannen]

I've intentionally labeled this issue as both a bug and an enhancement, since it's about two things:

1. a regression (bug) that we won't be able to fix
2. an enhancement that makes it easier to work around the regression and also makes it easier to disambiguate local factory method candidates in general

[marcphilipp]

Team decision: Let's go with @MethodSource("data()")