JMR-dev/LibreMediaConverter
1
0
Fork 0
Code Issues 16 Pull Requests Actions Packages Projects Releases Wiki Activity

Seven one-branch outcomes no test produces, each with a sibling that already models it #172

New Issue
Closed
opened 2026-09-02 02:15:03 +00:00 by JMR-dev · 1 comment
JMR-dev commented 2026-09-02 02:15:03 +00:00 (Migrated from github.com)
Copy Link
Copy Source

Seven outcomes no test produces

Each row below is a site where JaCoCo reports mi > 0 — a concrete instruction no test runs, not a
short-circuit combination of a compound condition. Measured on main at d354f64.

Site The outcome nothing produces Joins
codec/AndroidDeviceCodecs.kt:35 canDecode(InputProbe.UNPARSEABLE)'s early return false (mi=2) CodecVocabularyTest
model/ContainerCapabilities.kt:94 accepts(container, VideoCodec.NONE, mode) (mi=2) ContainerCapabilitiesTest
model/ContainerCapabilities.kt:323 repairVideo's keep-the-requested-codec arm (mi=3) ContainerCapabilitiesTest
model/ContainerCapabilities.kt:348 firstContainerHolding's ?: holders.firstOrNull() fallback (mi=4) ContainerCapabilitiesTest
model/ContainerCapabilities.kt:282 suggestions' exclude filter actually excluding something (mi=1) ContainerCapabilitiesTest
convert/OutputPublisher.kt:230 destinationIsKnownEmpty's ?: false (mi=2) OutputPublisherPublishTest
work/JobSnapshots.kt:31 the !isFile arm of the output takeIf (mi=2) JobSnapshotsTest

Notes on three of them

AndroidDeviceCodecs.kt:35 is the real implementation of the rule that
DeviceCodecs.PERMISSIVE models. The router's version is already covered through
an input the platform cannot parse routes to ffmpeg; this one is not, and it is the one that runs
on a device. CodecVocabularyTest exercises forTesting(...).canDecode(...) for known and unknown
names but never for the sentinel.

ContainerCapabilities.kt:94 is dead in production today — every caller guards NONE before
calling. It is in scope anyway because its audio twin at :101 has a dedicated test
(no audio track is accepted by every container in both modes). The asymmetry is the argument,
not the reachability — record that in the test's KDoc so a later reader does not mistake it for an
F4-style exemption that slipped through.

OutputPublisher.kt:230 — runCatching { ... }.getOrNull() ?: false. A provider that returns
no cursor must not read as "known empty". Reachable with the FakeProviders scaffolding #134 added
precisely so a provider can answer wrongly.

JobSnapshots.kt:31 — the sibling arm (an empty file) is already tested by
a staged file with nothing in it is not an output, and that test already stands up the WorkManager
fixture, so this is an addition to an existing harness, not a new one. The untested arm is a
recorded output path that no longer names a file at all.

Acceptance: one mutation per row

:35 delete the early return · :94 change true to false · :323 drop the arm so it falls to
else · :348 drop the ?: holders.firstOrNull() · :282 delete the .filter { it != exclude }
· :230 change ?: false to ?: true · :31 drop it.isFile && from the takeIf.

Every one must go red on its own test, then be restored.

## Seven outcomes no test produces Each row below is a site where JaCoCo reports `mi > 0` — a concrete instruction no test runs, not a short-circuit combination of a compound condition. Measured on `main` at `d354f64`. | Site | The outcome nothing produces | Joins | |---|---|---| | `codec/AndroidDeviceCodecs.kt:35` | `canDecode(InputProbe.UNPARSEABLE)`'s early `return false` (`mi=2`) | `CodecVocabularyTest` | | `model/ContainerCapabilities.kt:94` | `accepts(container, VideoCodec.NONE, mode)` (`mi=2`) | `ContainerCapabilitiesTest` | | `model/ContainerCapabilities.kt:323` | `repairVideo`'s keep-the-requested-codec arm (`mi=3`) | `ContainerCapabilitiesTest` | | `model/ContainerCapabilities.kt:348` | `firstContainerHolding`'s `?: holders.firstOrNull()` fallback (`mi=4`) | `ContainerCapabilitiesTest` | | `model/ContainerCapabilities.kt:282` | `suggestions`' `exclude` filter actually excluding something (`mi=1`) | `ContainerCapabilitiesTest` | | `convert/OutputPublisher.kt:230` | `destinationIsKnownEmpty`'s `?: false` (`mi=2`) | `OutputPublisherPublishTest` | | `work/JobSnapshots.kt:31` | the `!isFile` arm of the output `takeIf` (`mi=2`) | `JobSnapshotsTest` | ## Notes on three of them **`AndroidDeviceCodecs.kt:35`** is the real implementation of the rule that `DeviceCodecs.PERMISSIVE` models. The router's version is already covered through `an input the platform cannot parse routes to ffmpeg`; this one is not, and it is the one that runs on a device. `CodecVocabularyTest` exercises `forTesting(...).canDecode(...)` for known and unknown names but never for the sentinel. **`ContainerCapabilities.kt:94`** is dead in production today — every caller guards `NONE` before calling. It is in scope anyway because its audio twin at `:101` has a dedicated test (`no audio track is accepted by every container in both modes`). **The asymmetry is the argument, not the reachability** — record that in the test's KDoc so a later reader does not mistake it for an F4-style exemption that slipped through. **`OutputPublisher.kt:230`** — `runCatching { ... }.getOrNull() ?: false`. A provider that returns no cursor must not read as "known empty". Reachable with the `FakeProviders` scaffolding #134 added precisely so a provider can answer wrongly. **`JobSnapshots.kt:31`** — the sibling arm (an empty file) is already tested by `a staged file with nothing in it is not an output`, and that test already stands up the WorkManager fixture, so this is an addition to an existing harness, not a new one. The untested arm is a recorded output path that no longer names a file at all. ## Acceptance: one mutation per row `:35` delete the early return · `:94` change `true` to `false` · `:323` drop the arm so it falls to `else` · `:348` drop the `?: holders.firstOrNull()` · `:282` delete the `.filter { it != exclude }` · `:230` change `?: false` to `?: true` · `:31` drop `it.isFile &&` from the `takeIf`. Every one must go red on its own test, then be restored.
JMR-dev commented 2026-09-02 03:09:56 +00:00 (Migrated from github.com)
Copy Link
Copy Source

Correction from the implementation, so the next coverage read does not re-derive it.

JobSnapshots.kt:31's missed arm is not the one this ticket named. The body says !isFile — "a recorded output path that no longer names a file". That arm is already covered, by the reclaimed fixture in a staged file with nothing in it is not an output.

The arm with mi=2 is path == null: a job carrying no output path at all, which is what a still-running job in the same tag query looks like. getWorkInfosByTagFlow returns it alongside the finished ones, because the tag is the worker class and every attempt ever enqueued carries it.

The test in #180 covers that arm, and asserts the consequence rather than the null check: such a job must not be offered as a result, so Reattachment.choose has to walk past it. Mutation: drop the ?. in path?.let(::File).

Also from the same PR: ContainerCapabilities:282 is not a gap and is not closed. Its .filter { it != exclude } cannot drop anything — on the shared container repair always changes at least one codec, and the single call site passing a non-default exclude (validateVideo:186) excludes a spec carrying VideoCodec.COPY while every repaired candidate carries NONE. F4-shaped, recorded rather than covered.

Correction from the implementation, so the next coverage read does not re-derive it. **`JobSnapshots.kt:31`'s missed arm is not the one this ticket named.** The body says `!isFile` — "a recorded output path that no longer names a file". That arm is already covered, by the `reclaimed` fixture in `a staged file with nothing in it is not an output`. The arm with `mi=2` is **`path == null`**: a job carrying no output path at all, which is what a still-running job in the same tag query looks like. `getWorkInfosByTagFlow` returns it alongside the finished ones, because the tag is the worker class and every attempt ever enqueued carries it. The test in #180 covers that arm, and asserts the consequence rather than the null check: such a job must not be offered as a result, so `Reattachment.choose` has to walk past it. Mutation: drop the `?.` in `path?.let(::File)`. Also from the same PR: **`ContainerCapabilities:282` is not a gap** and is not closed. Its `.filter { it != exclude }` cannot drop anything — on the shared container `repair` always changes at least one codec, and the single call site passing a non-default `exclude` (`validateVideo:186`) excludes a spec carrying `VideoCodec.COPY` while every repaired candidate carries `NONE`. F4-shaped, recorded rather than covered.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
above-cut
Worked autonomously overnight: local, JVM-verifiable, no product decision
 accessibility
Barrier affecting people with disabilities
 backlog
Held for manual review: product/UX call, CI/workflow, hardware, or unverifiable here
 bug
Something isn't working
 confirmed
Reviewer demonstrated the defect
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 plausible
Reviewer could not fully demonstrate it; treat as unproven
 question
Further information is requested
 sev:high
High severity
 sev:low
Low severity
 sev:medium
Medium severity
 wontfix
This will not be worked on
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
JMR-dev
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: JMR-dev/LibreMediaConverter#172