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

W4: seven ViewModel methods with no coverage, and two else arms #157

New Issue
Closed
opened 2026-08-27 11:59:08 +00:00 by JMR-dev · 0 comments
JMR-dev commented 2026-08-27 11:59:08 +00:00 (Migrated from github.com)
Copy Link
Copy Source

Small, mechanical, and worth doing in one pass: methods and arms with no coverage at all.

Seven methods, zero coverage

ConversionViewModel:

method line
setContainer 321
setVideoCodec 323
setAudioCodec 325
applySuggestion 327
setQuality 329
setEnginePreference 330
cancel 519–520

setPreset (320) sitting right beside them is covered, which is the tell: these are reachable from the JVM suite by the same route, and nothing has asked.

Each is a one-line _settings.update { … }. The test is correspondingly small, but not empty — assert that the setter changes its own field and leaves the rest of OutputSpec alone. setContainer copies into spec, so a version that rebuilt spec from a preset would pass a test that only checked the container.

cancel() wants workManager::cancelWorkById to be reached only when activeWorkId is non-null; both sides of that ?.let are worth a test, since cancelling with no active job must not throw.

Two else arms

  • ConversionState.pendingSave() — else -> null at 139
  • currentInput() — else -> null at 615–618, plus the Converting / Waiting / Converted arms

pendingSave() is the one that matters: ConverterScreen:80 and JoinScreen:52 both read it to choose the destination MIME type, and its Failed -> retry arm is what makes a retry after a failed save reuse the original type. The else is what every other state falls to.

JoinState.pendingSave()'s else (JoinViewModel.kt:72) is the same arm on the join side.

Relationship to W3

W3 tests that the screen calls these methods. This tests that the methods do the right thing. Neither implies the other, and running only one of them leaves a real hole — W3 alone passes against setters that all write the same field; this alone passes against a screen wired to the wrong ones.

Done when

Every method above is covered and each is killed by a mutation that changes which field it writes — not merely by deleting the call.

Small, mechanical, and worth doing in one pass: methods and arms with no coverage at all. ## Seven methods, zero coverage `ConversionViewModel`: | method | line | |---|---| | `setContainer` | 321 | | `setVideoCodec` | 323 | | `setAudioCodec` | 325 | | `applySuggestion` | 327 | | `setQuality` | 329 | | `setEnginePreference` | 330 | | `cancel` | 519–520 | `setPreset` (320) sitting right beside them **is** covered, which is the tell: these are reachable from the JVM suite by the same route, and nothing has asked. Each is a one-line `_settings.update { … }`. The test is correspondingly small, but not empty — assert that the setter changes *its own* field and leaves the rest of `OutputSpec` alone. `setContainer` copies into `spec`, so a version that rebuilt `spec` from a preset would pass a test that only checked the container. `cancel()` wants `workManager::cancelWorkById` to be reached only when `activeWorkId` is non-null; both sides of that `?.let` are worth a test, since cancelling with no active job must not throw. ## Two `else` arms - `ConversionState.pendingSave()` — `else -> null` at 139 - `currentInput()` — `else -> null` at 615–618, plus the `Converting` / `Waiting` / `Converted` arms `pendingSave()` is the one that matters: `ConverterScreen:80` and `JoinScreen:52` both read it to choose the destination MIME type, and its `Failed -> retry` arm is what makes a retry after a failed save reuse the original type. The `else` is what every other state falls to. `JoinState.pendingSave()`'s `else` (`JoinViewModel.kt:72`) is the same arm on the join side. ## Relationship to W3 W3 tests that the *screen* calls these methods. This tests that the methods *do the right thing*. Neither implies the other, and running only one of them leaves a real hole — W3 alone passes against setters that all write the same field; this alone passes against a screen wired to the wrong ones. ## Done when Every method above is covered and each is killed by a mutation that changes which field it writes — not merely by deleting the call.
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#157