On Thu, 17 Nov 2022 22:10:28 GMT, Christoph Langer <[email protected]> wrote:
> > Generally, there are two ways to fix issues like this:
> >
> > 1. force the locale to be as needed
> > 2. accommodate the locale being used
> >
> > 1 is simpler; 2 seems like a better solution.
>
> Not sure I understand correctly - Option 1 would mean that a locale can be
> picked by some setting and Option 2 means the current behavior - use the
> system locale, right? But how would option 1 then be simpler than option 2,
> given that I perceive option 2 as current status quo? 😄
>
> However, with option 2, I guess my proposed testfix would be the right thing
> to do, correct?
>
> > In general, we don't do a lot of testing in non-English locales. (Our
> > bad.). Is this the only (javadoc?) test that fails?
>
> I'm only aware of this one ATM.
My take is that Option (1) is "golden output". You fixate the locale and
capture the output. Then every run you force that same locale (yes, there's a
javadoc option called `-locale`) and compare the output of the run with the
golden output.
Option (2) is "property testing". You assert some property of the system. In
this case, the property, albeit a bit implicit, looks something like this:
whatever locale is effective for this javadoc run, is used by `@value` to
format its arguments
Your test additionally assumes that "if no locale is specified, the default
locale is used". Which is true.
-------------
PR: https://git.openjdk.org/jdk/pull/11177
