Context
The fork's testing effort — substantial, and carefully documented in TESTING.md — targets
driver and web-ui. The core module was left out:
| Module |
Production |
Tests |
core |
4,384 L / 38 files |
71 L / 1 file |
driver |
3,753 L / 24 f |
6,042 L / 21 f |
web-ui |
3,179 L / 15 f |
2,148 L / 8 f |
metadata |
390 L / 3 f |
247 L / 2 f |
agent |
261 L / 3 f |
0 |
core's only test is BytesUtilsCharacterizationTest, a characterization of the endianness
helpers.
It is the least covered module, and it is the one that produces the bytes written to the card.
It holds the readers and writers for all three pack formats (binary, archive, fs), plus
XXTEACipher, PackAssetsCompression, VorbisEncoder, AudioConversion and
ImageConversion. The hardening work done on driver establishes that the index and its
installation are correct — but nothing currently establishes that the content written into
.content/ faithfully represents the source pack.
The risk is not hypothetical, since driver builds on these classes: silent corruption
introduced during conversion would pass every existing specification.
Description
Establish coverage for core, starting with the property that matters most and costs least to
write: the round trip. A pack synthesised in code, written and then read back, must yield
an equivalent model — for each format, and for each cross-format path the library offers.
Follow the distinction TESTING.md already sets out: characterize what the code does today,
including where it is wrong, then convert to specifications as defects are fixed.
Affected files
core/src/test/java/studio/core/v1/ — most of the work, to be created
core/src/main/java/studio/core/v1/reader/{binary,archive,fs}/ — under test
core/src/main/java/studio/core/v1/writer/{binary,archive,fs}/ — under test
core/src/main/java/studio/core/v1/utils/XXTEACipher.java — test vectors
core/src/main/java/studio/core/v1/utils/PackAssetsCompression.java — under test
- possibly a shared
PackFixtures, along the lines of DriverTestSupport
Implementation plan
- A fixture builder: a parameterisable synthetic
StoryPack (node count, assets present or
absent, enriched metadata or not). No device data committed, as driver already does.
- Per-format round trip:
write → read → structural comparison of the model.
- Cross-format round trip:
binary → archive → binary, and the other paths exposed by
LibraryService. This is what a user actually exercises.
XXTEACipher: known vectors, plus the decipher(cipher(x)) == x property.
PackAssetsCompression: compress then decompress, and hasCompressedAssets on a mixed
pack.
- Failure paths: truncated file, invalid magic number, asset referenced but missing.
Characterize what happens today — several of these likely produce an unhelpful exception,
or a partial pack.
- Extend the "Coverage map" table in
TESTING.md.
Acceptance criteria
Complexity
L — the work splits cleanly per format and can land across several PRs.
Context
The fork's testing effort — substantial, and carefully documented in
TESTING.md— targetsdriverandweb-ui. Thecoremodule was left out:coredriverweb-uimetadataagentcore's only test isBytesUtilsCharacterizationTest, a characterization of the endiannesshelpers.
It is the least covered module, and it is the one that produces the bytes written to the card.
It holds the readers and writers for all three pack formats (
binary,archive,fs), plusXXTEACipher,PackAssetsCompression,VorbisEncoder,AudioConversionandImageConversion. The hardening work done ondriverestablishes that the index and itsinstallation are correct — but nothing currently establishes that the content written into
.content/faithfully represents the source pack.The risk is not hypothetical, since
driverbuilds on these classes: silent corruptionintroduced during conversion would pass every existing specification.
Description
Establish coverage for
core, starting with the property that matters most and costs least towrite: the round trip. A pack synthesised in code, written and then read back, must yield
an equivalent model — for each format, and for each cross-format path the library offers.
Follow the distinction
TESTING.mdalready sets out: characterize what the code does today,including where it is wrong, then convert to specifications as defects are fixed.
Affected files
core/src/test/java/studio/core/v1/— most of the work, to be createdcore/src/main/java/studio/core/v1/reader/{binary,archive,fs}/— under testcore/src/main/java/studio/core/v1/writer/{binary,archive,fs}/— under testcore/src/main/java/studio/core/v1/utils/XXTEACipher.java— test vectorscore/src/main/java/studio/core/v1/utils/PackAssetsCompression.java— under testPackFixtures, along the lines ofDriverTestSupportImplementation plan
StoryPack(node count, assets present orabsent, enriched metadata or not). No device data committed, as
driveralready does.write→read→ structural comparison of the model.binary→archive→binary, and the other paths exposed byLibraryService. This is what a user actually exercises.XXTEACipher: known vectors, plus thedecipher(cipher(x)) == xproperty.PackAssetsCompression: compress then decompress, andhasCompressedAssetson a mixedpack.
Characterize what happens today — several of these likely produce an unhelpful exception,
or a partial pack.
TESTING.md.Acceptance criteria
XXTEACiphercovered by vectors and by its involution propertyKNOWN GAPmarked as suchTESTING.mdupdated (coverage map and counts)mvn -Dskip.installnodeyarn=true -Dskip.yarn=true testgreen on Linux and WindowsComplexity
L — the work splits cleanly per format and can land across several PRs.