tree 0f28d1a51530afee58eaf991ecc67cec5e765605
parent bd1ed0e04e15d81a8a1f9eae1ce14c0d2829bb35
author Neil Fuller <nfuller@google.com> 1411652620 +0100
committer Neil Fuller <nfuller@google.com> 1412008620 +0100

Fixing formatDouble scientific notation tests

Rather than having perpetually failing test cases the current Android
behavior has been captured and compared against the Android docs.
The "problem cases" have been merged into one test.

The tests now execute all format() calls and report at the end if any
fail, rather than failing at the first problem. This makes debugging
and comparison easier.

Each output from the affected tests has been inspected. The formatter
settings and some justification have been documented in the tests for
later engineers.

For format() with scientific notation the desired behavior is often
unclear because some parts of the docs contradict others about how
much the min/max integer/fraction values are used.

Many of the "problem cases" were the result of the significant
digit rules not being obeyed by the RI which probably introduced
doubt as to whether Android/ICU was correct.

None of the results were found to be actually wrong, i.e. they appear
to output the input number to the correct amount of precision.

When using min/max integer/fraction digits (i.e. not using '@'
characters), apparently by design DecimalFormat does
not produce strings that make clear the number of significant digits
used to generate them. e.g. 1.0 output to 4 sig digits does not output
1.000E0, but may output 1.0E0 or 1E0 depending on the pattern.

Bug reports have been created to record why some categories of results
are ok or to follow up where behavior is open to interpretation, e.g.
the choice of exponent, or whether leading or trailing zeros are
present in the output.

Bug: 17654561
Bug: 17653864
Bug: 17652647
Bug: 17652196
Bug: 12781028

(cherry picked from commit 279c42d3171bb72601f24de842a8770f903edcfe)

Change-Id: I2968e1d977a8a4e40381da330e38209a268d90fb