Skip to content

Support CharSequence argument for Fallback String-to-Object Conversion #4819

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
Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Support CharSequence argument for Fallback String-to-Object Conversion #4819

wants to merge 1 commit into from

Conversation

sbrannen
Copy link
Member

@sbrannen sbrannen commented Aug 8, 2025 •
edited
Loading

Prior to this commit, the "Fallback String-to-Object Conversion" support for parameterized tests supported factory constructors and methods that accepted a single String argument.

This commit relaxes that restriction to support factory constructors and methods that accept either a single String argument or a single CharSequence argument, since the original source String can always be supplied to an Executable that accepts a CharSequence.

Note that this change is available to third parties via ConversionSupport in junit-platform-commons, which junit-jupiter-params utilizes.

@sbrannen sbrannen mentioned this pull request Aug 8, 2025
Open
@sbrannen sbrannen self-assigned this Aug 8, 2025
@sbrannen sbrannen requested a review from marcphilipp August 8, 2025 08:39
@sbrannen
Copy link
Member Author

sbrannen commented Aug 8, 2025 •
edited
Loading

In my opinion, both the feature and the implementation are straightforward.

However, after having put a little more thought into it, I believe we may want to alter the implementation to support backward compatibility.

For example, if an existing code base has overloaded from(String) and from(CharSequence) factory methods, JUnit would have used from(String) prior to 6.0. However, with this change in 6.0, JUnit will ignore both from(...) factory methods, since we only honor a single, unambiguous factory method.

Thus, we should ideally make a first pass to find String factory methods/constructors to support backward compatibility and then make an additional pass to find CharSequence factories.

In other words, I think this new feature should effectively be a "fallback for the fallback". 😉

I'm happy to implement that, but I wanted to bring up the topic for discussion first.

@sbrannen sbrannen force-pushed the issues/4815-CharSequence-support-in-fallback-conversion branch from 843e966 to da86bdf Compare August 8, 2025 12:06
@sbrannen sbrannen marked this pull request as draft August 8, 2025 12:09
@sbrannen
Copy link
Member Author

sbrannen commented Aug 8, 2025

For example, if an existing code base has overloaded from(String) and from(CharSequence) factory methods, JUnit would have used from(String) prior to 6.0. However, with this change in 6.0, JUnit will ignore both from(...) factory methods, since we only honor a single, unambiguous factory method.

I've marked this PR as a draft until I've reworked the implementation to avoid introducing that regression.

@sbrannen
Support CharSequence argument for Fallback String-to-Object Conversion
02aaf4d 
Prior to this commit, the Fallback String-to-Object Conversion support
for parameterized tests supported factory constructors and methods that
accepted a single String argument.

This commit relaxes that restriction to support factory constructors
and methods that accept either a single String argument or a single
CharSequence argument, since the original source String can always be
supplied to an Executable that accepts a CharSequence. For backward
compatibility, the search algorithm gives precedence to factories that
accept String arguments, only falling back to factories that accept
CharSequence arguments if necessary.

Note that this change is available to third parties via
ConversionSupport in junit-platform-commons, which junit-jupiter-params
utilizes.

Closes junit-team#4815
@sbrannen sbrannen force-pushed the issues/4815-CharSequence-support-in-fallback-conversion branch from da86bdf to 02aaf4d Compare August 8, 2025 13:47
@sbrannen sbrannen marked this pull request as ready for review August 8, 2025 13:52
@sbrannen
Copy link
Member Author

sbrannen commented Aug 8, 2025

For example, if an existing code base has overloaded from(String) and from(CharSequence) factory methods, JUnit would have used from(String) prior to 6.0. However, with this change in 6.0, JUnit will ignore both from(...) factory methods, since we only honor a single, unambiguous factory method.

I've marked this PR as a draft until I've reworked the implementation to avoid introducing that regression.

I have addressed this, force pushed, and removed draft status.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@sormuras sormuras sormuras approved these changes

@marcphilipp marcphilipp Awaiting requested review from marcphilipp

Assignees

@sbrannen sbrannen

Labels
component: Jupiter component: Platform theme: parameterized tests type: enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Extend fallback conversion to support CharSequence factory arguments
2 participants
@sbrannen @sormuras