Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Local qualified @MethodSource factory method name treated differently than FQMN #3266

Closed
5 tasks done
sbrannen opened this issue Apr 22, 2023 · 2 comments
Closed
5 tasks done

Local qualified @MethodSource factory method name treated differently than FQMN #3266

sbrannen opened this issue Apr 22, 2023 · 2 comments
Assignees
@sbrannen
Labels
component: Jupiter theme: diagnostics theme: parameterized tests theme: programming model type: bug type: enhancement
Milestone
5.9.3

Comments

@sbrannen
Copy link
Member

sbrannen commented Apr 22, 2023 •
edited

Overview

This issue is both a bug report and an enhancement proposal.

Bug

When the @MethodSource factory methods involved are overloaded, a local qualified method name (LQMN) is not treated the same as a fully-qualified method name (FQMN).

Specifically, if the user provides a FQMN without specifying the parameter list, JUnit Jupiter will find the factory method that accepts zero arguments. Whereas, if the user provides an LQMN without specifying the parameter list, JUnit Jupiter will fail to find the factory method.

@MethodSource("org.example.MyClass#factoryMethod()") // works
@MethodSource("org.example.MyClass#factoryMethod") // works

@MethodSource("factoryMethod()") // works
@MethodSource("factoryMethod") // does NOT work

Enhancement

When a user provides a FQMN or LQMN without specifying the parameter list, JUnit Jupiter should fall back to the same lenient search semantics that are used to locate a "default" local factory method.

Related Issues

Deliverables

  • Fix bug
  • Implement enhancement
  • Update Javadoc
  • Update Release Notes
  • Backport to 5.9.x
@sbrannen sbrannen added this to the 5.9.3 milestone Apr 22, 2023
@sbrannen sbrannen self-assigned this Apr 22, 2023
This was referenced Apr 22, 2023
Closed
Closed
@sbrannen
Copy link
Member Author

Reopening to backport to 5.9.x.

@sbrannen sbrannen reopened this Apr 23, 2023
sbrannen added a commit that referenced this issue Apr 23, 2023
@sbrannen
Treat overloaded local & external @MethodSource factory methods equally
82f1f4b 
Prior to this commit, given overloaded @MethodSource factory methods, a
local qualified method name (LQMN) was not treated the same as a
fully-qualified method name (FQMN).

Specifically, if the user provided a FQMN without specifying the
parameter list, JUnit Jupiter would find the factory method that
accepts zero arguments. Whereas, if the user provided an LQMN without
specifying the parameter list, JUnit Jupiter would fail to find the
factory method.

This commit fixes that bug by reworking the internals of
MethodArgumentsProvider so that overloaded local and external factory
methods are looked up with the same semantics.

The commit also improves diagnostics for failure to find a factory
method specified via LQMN by falling back to the same lenient search
semantics that are used to locate a "default" local factory method.

Furthermore, this commit modifies the internals of
MethodArgumentsProvider so that it consistently throws
PreconditionViolationExceptions for user configuration errors.

This commit also introduces additional tests for error use cases.

See: #3130, #3131
Closes: #3266
@sbrannen
Copy link
Member Author

Backported to 5.9.x in 82f1f4b

@marcphilipp marcphilipp mentioned this issue May 1, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sbrannen sbrannen

Labels
component: Jupiter theme: diagnostics theme: parameterized tests theme: programming model type: bug type: enhancement
Projects
None yet
Milestone
5.9.3
Development

No branches or pull requests
1 participant
@sbrannen