You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the MBCS test suite pulls in test data from unicode.org public data, to be able to compare what the JDK produces, versus what is expected based on the test data.
not keeping 2 copies of files, but referring to a single copy that is in a single location (possibly pulled in by the getDependencies job)
pulling test data as part of getDependencies job (and possibly noting when new data shows up at the unicode site)
Noting that in a recent update to the MBCS suite #5150, 9 of 13 files were test data, while the 4 src files changed only required 10 lines of code changed. Managing the test data differently would reduce maintenance costs of this suite.
The text was updated successfully, but these errors were encountered:
Currently the MBCS test suite pulls in test data from unicode.org public data, to be able to compare what the JDK produces, versus what is expected based on the test data.
For expediency, a copy of this test data is in the MBCS_Tests directory. In fact, certain files are duplicate within subdirectories like https://github.com/adoptium/aqa-tests/blob/master/functional/MBCS_Tests/codepoint/data/UnicodeData-15.1.0.txt and https://github.com/adoptium/aqa-tests/blob/master/functional/MBCS_Tests/unicode/data/UnicodeData-15.1.0.txt.
We can improve this in 2 ways:
Noting that in a recent update to the MBCS suite #5150, 9 of 13 files were test data, while the 4 src files changed only required 10 lines of code changed. Managing the test data differently would reduce maintenance costs of this suite.
The text was updated successfully, but these errors were encountered: