FloatingPointAssertionWithinEpsilonTest depends on default locale #4815
Description
FloatingPointAssertionWithinEpsilonTest expresses locale agnostic checks, but FloatingPointAssertionWithinEpsilon is locale aware so the test fails in environments that don't use . as decimal separator.
Given
for lang in C.UTF-8 da_DK.UTF-8 ; do
LANG=$lang mvn verify -pl core -am -Dsurefire.failIfNoSpecifiedTests=false -Dtest=FloatingPointAssertionWithinEpsilonTest
donethe second execution will fail with
[INFO] Running com.google.errorprone.bugpatterns.FloatingPointAssertionWithinEpsilonTest
[ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.201 s <<< FAILURE! - in com.google.errorprone.bugpatterns.FloatingPointAssertionWithinEpsilonTest
[ERROR] com.google.errorprone.bugpatterns.FloatingPointAssertionWithinEpsilonTest.positiveCase Time elapsed: 0.138 s <<< FAILURE!
Did not see an error on line 19 matching 6.0e-08. All errors:
/FloatingPointAssertionWithinEpsilonPositiveCases.java:19: warning: [FloatingPointAssertionWithinEpsilon] This fuzzy equality check is using a tolerance less than the gap to the next number (which is ~6,0e-08). You may want a less restrictive tolerance, or to assert equality.
assertThat(1.0f).isWithin(1e-20f).of(1.0f);
^
(see https://errorprone.info/bugpattern/FloatingPointAssertionWithinEpsilon)
Did you mean 'assertThat(1.0f).isEqualTo(1.0f);'?
FloatingPointAssertionWithinEpsilon's use of default-locale String.format (heh) is consistent with Error Prone in general, so the error is probably that the test cases in question ignore the default locale, or alternatively that a specific default locale is assumed and unspecified.