mirror of
https://github.com/HDFGroup/hdf5.git
synced 2026-09-25 04:09:44 +03:00
Scot Breitenfeld
4e445a1997
JUnit4's default method sorter (MethodSorters.DEFAULT) orders test methods by a hash of the method name, not declaration order -- so any rename or addition shifts the whole run order unpredictably relative to a hand-maintained golden file. Both java/test/TestH5Z.java (added this session, 13 methods) and java/src-jni/test/TestH5Z.java (5 methods, unmodified but apparently never correctly regenerated after the testH5Zget_filter_info2 -> testH5Zget_filter_class_info rename) had golden JUnit-TestH5Z.txt files that didn't match the real hash-sorted order, both confirmed by computing Java's documented String.hashCode() algorithm directly and matching it byte-for-byte against actual CI failure output. Verified against upstream develop (an unrelated, currently-open develop-based PR): this test passes cleanly there, confirming the mismatch was never a general JUnit/reflection flakiness -- it was always a genuinely wrong reference file. Fixed by adding @FixMethodOrder(MethodSorters.NAME_ASCENDING) to both classes (alphabetical by method name, a properly documented and stable JUnit4 ordering mode) and regenerating both reference files to match the resulting deterministic order. This also makes the test immune to the same class of breakage going forward: alphabetical order is computable by inspection, unlike the hash order.