Skip to content

core module has almost no test coverage #2

Description

@lgnap

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

  1. 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.
  2. Per-format round trip: writeread → structural comparison of the model.
  3. Cross-format round trip: binaryarchivebinary, and the other paths exposed by
    LibraryService. This is what a user actually exercises.
  4. XXTEACipher: known vectors, plus the decipher(cipher(x)) == x property.
  5. PackAssetsCompression: compress then decompress, and hasCompressedAssets on a mixed
    pack.
  6. 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.
  7. Extend the "Coverage map" table in TESTING.md.

Acceptance criteria

  • Round trip covered for all three formats
  • Cross-format conversions covered in both directions
  • XXTEACipher covered by vectors and by its involution property
  • Failure paths characterized, with KNOWN GAP marked as such
  • No device data or third-party content committed
  • TESTING.md updated (coverage map and counts)
  • mvn -Dskip.installnodeyarn=true -Dskip.yarn=true test green on Linux and Windows

Complexity

L — the work splits cleanly per format and can land across several PRs.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesthelp wantedExtra attention is needed

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions