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.

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

Make @DefaultLocale and @DefaultTimeZone more flexible #660

Open
Michael1993 opened this issue Aug 25, 2022 · 5 comments · May be fixed by #770
Open

Make @DefaultLocale and @DefaultTimeZone more flexible #660

Michael1993 opened this issue Aug 25, 2022 · 5 comments · May be fixed by #770

Comments

@Michael1993
Copy link
Member

We could provide new interfaces (TimeZoneProvider and LocaleProvider) and a way for the user to pull their own implementation into DefaultLocaleExtension and DefaultTimeZoneExtension. I.e.:

@DefaultLocale(localeProvider = MyLocaleProvider.class)

class MyLocaleProvider implements LocaleProvider {

  @Override
  public Locale getLocale(ExtensionContext extensionContext) {
    [...]
  }

}

This way people can have custom logic evaluated at runtime to decide the locale/timezone for any given test.

Note: We can instantiate such classes with JUnit 5's ReflectionSupport.newInstance().

@Michael1993
Copy link
Member Author

This could "make up" for the fact that we chose the restrictive Locale.Builder in #658.

@Michael1993
Copy link
Member Author

Please provide feedback.

@Bukama
Copy link
Member

Bukama commented Aug 26, 2022

As discussed yesterday: I'm open for it, but I think it's a very special case that I need to provide a user defined provider. For me it's important that the default implementation we provide should cover 99%+ usage, so users can normally use the extension in the same way as the current one, meaning without defining a provider

@Bukama
Copy link
Member

Bukama commented Oct 6, 2022

On today's maintainers meeting also @beatngu13 noticed that he's open to give users the possibility to create their own provider.

@nipafx
Copy link
Member

nipafx commented Nov 8, 2022

I think it's a good idea and very in line with "[Pioneer] does not limit itself to proven ideas with wide application but is purposely open to experiments". 😉

@Michael1993 Michael1993 linked a pull request Oct 6, 2023 that will close this issue
18 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants