Summary
tests/testIDT.cpp embeds large numeric table literals next to tests that already load rawtoaces_data JSON under DATA_PATH. That duplicates on-disk data, bloats the file (thousands of lines), and is hard to review. This work replaces those patterns with lighter assertions: spot-checks for loaded fixtures, and fingerprints for transformation outputs.
Background (for newcomers)
These tests exercise IDT-related loading and math. The intended reader is someone picking up a day-sized task (for example during ASWF Dev Days) who may not have touched this suite before. The goal is to preserve regression coverage while making testIDT.cpp easier to maintain—without adopting snapshot-testing tooling.
Where to look
tests/testIDT.cpp — large double / table literals interleaved with OIIO_CHECK_* assertions.- Fixture root:
DATA_PATH → ../_deps/rawtoaces_data-src/data/ (camera, CMF, and related JSON).
- Search for big brace-initialized arrays and loops comparing every row to a literal.
Suggested direction (not a prescription)
Fixture data (already on disk) — When the test only checks that a JSON asset was read and parsed correctly:
- Assert structure (dimensions, channel keys, sizes).
- Compare a few rows only — e.g. first and last couple of rows of each relevant channel — instead of embedding the full table in C++.
Computed / transformation output — When the assertion is about pipeline output, not raw file bytes:
- Prefer a stable fingerprint (checksum or hash over a clearly defined serialization of the result).
- Store an expected fingerprint constant in the test and assert computed fingerprint == expected.
Rough success criteria: meaningful shrink of testIDT.cpp where literals were redundant; regressions still caught (bad dimensions, parse errors, broken transforms); fingerprints deterministic in CI (or platform quirks documented).
Summary
tests/testIDT.cppembeds large numeric table literals next to tests that already loadrawtoaces_dataJSON underDATA_PATH. That duplicates on-disk data, bloats the file (thousands of lines), and is hard to review. This work replaces those patterns with lighter assertions: spot-checks for loaded fixtures, and fingerprints for transformation outputs.Background (for newcomers)
These tests exercise IDT-related loading and math. The intended reader is someone picking up a day-sized task (for example during ASWF Dev Days) who may not have touched this suite before. The goal is to preserve regression coverage while making
testIDT.cppeasier to maintain—without adopting snapshot-testing tooling.Where to look
tests/testIDT.cpp— largedouble/ table literals interleaved withOIIO_CHECK_*assertions.DATA_PATH→../_deps/rawtoaces_data-src/data/(camera, CMF, and related JSON).Suggested direction (not a prescription)
Fixture data (already on disk) — When the test only checks that a JSON asset was read and parsed correctly:
Computed / transformation output — When the assertion is about pipeline output, not raw file bytes:
Rough success criteria: meaningful shrink of
testIDT.cppwhere literals were redundant; regressions still caught (bad dimensions, parse errors, broken transforms); fingerprints deterministic in CI (or platform quirks documented).