Overloaded method accepting arguments clashes with intended @MethodSource factory method #3080
Description
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
@MethodSourcefactory method resolution #3001
Deliverables
- Determine if there are any improvements that can be made and otherwise document the status quo (including workarounds).