W3 (#156): the screen wiring, and a narrower hazard than the ticket claimed

The stateful outer composables hand `ConverterScreenContent` and `JoinScreenContent` a list of `viewModel::` references. No test in the suite had ever seen that list: the content tests build their own `ConverterActions`, so they drive the stateless inner and never touch the wiring. THE TICKET'S PREMISE WAS HALF WRONG, AND CHECKING BEAT ASSUMING. #156 was filed claiming a transposition of any two of seventeen bindings would survive the suite. Measured instead of trusted: onVideoCodec <-> onAudioCodec -> REJECTED: "Inapplicable candidate(s): fun setAudioCodec(codec: AudioCodec)" onCancel <-> onReset -> COMPILES Every typed binding -- container, both codecs, preset, suggestion, quality, engine preference -- takes a distinct parameter type, so the compiler is already the test. Writing assertions against those transpositions would have been theatre, and this file says so rather than quietly including them. WHAT IS ACTUALLY AT RISK is the `() -> Unit` bindings, which are interchangeable to the compiler: two on the converter screen (onCancel, onReset) and *three* on the join screen (onJoin, onCancel, onReset). A Cancel button that discards the finished file, a Start-over that leaves it on screen, or a Join button that cancels -- each is one wrong word and each ships. I got that wrong in the first check too: an early run reported the onCancel/ onReset swap as rejected, from a grep-and-exit-code test that misread a stale build. Re-running it properly printed BUILD SUCCESSFUL with the swap in place. THE SEAM. `converterActions(viewModel, onPickInput, onConvert, onSave)` and `joinActions(viewModel, onPickInputs, onSave)`. The launcher-backed actions stay parameters -- they need an ActivityResultLauncher, which is the part that genuinely needs a composition, and keeping them out means the rest needs none. Told apart by effect rather than by a recording double: `reset()` sets the state to Idle, `cancel()` with no active job leaves it alone (`activeWorkId?.let`, which SettingsEditsTest pins). Mutations -- every transposition caught, each by two tests: converter onCancel <-> onReset | 2 tests join onJoin <-> onCancel | 2 tests join onReset <-> onCancel | 2 tests a typed binding dropped to {} | 1 test a launcher action rerouted | 1 test The two-test symmetry is deliberate: one direction alone passes against a wiring with BOTH actions bound to the same method, which is what a copy-pasted line produces. Three guard assertions earned their place during writing -- the picks land through an injected dispatcher, and without `ParkedPickDispatcher.runAll()` all three state-based tests sat on Idle and would have asserted nothing. They failed loudly instead of passing quietly. `@UnstableApi` on both builders, per CLAUDE.md; lint caught their absence, as it did in W1. 525 -> 537 tests, 88.0% -> 88.9% line, 70.5% -> 75.4% branch. Gate green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-29 10:56:44 -05:00
parent 7595177e81
commit 6f3966cc69
3 changed files with 313 additions and 14 deletions
@@ -94,24 +94,61 @@ fun ConverterScreen(modifier: Modifier = Modifier, viewModel: ConversionViewMode
        state = state,
        settings = settings,
        validation = validation,
-        actions = ConverterActions(
+        actions = converterActions(
+            viewModel = viewModel,
            onPickInput = { pickInput.launch(arrayOf("*/*")) },
-            onPreset = viewModel::setPreset,
-            onContainer = viewModel::setContainer,
-            onVideoCodec = viewModel::setVideoCodec,
-            onAudioCodec = viewModel::setAudioCodec,
-            onSuggestion = viewModel::applySuggestion,
-            onQuality = viewModel::setQuality,
-            onEnginePreference = viewModel::setEnginePreference,
            onConvert = { requestNotifications.launch(Manifest.permission.POST_NOTIFICATIONS) },
-            onCancel = viewModel::cancel,
            onSave = { suggestedName -> chooseDestination.launch(suggestedName) },
-            onReset = viewModel::reset,
        ),
        modifier = modifier,
    )
 }

+/**
+ * Which of the ViewModel's methods each affordance on the screen calls.
+ *
+ * ## Why this is a function rather than an argument list
+ *
+ * It was an argument list, inside [ConverterScreen], which no test reached: `ConverterScreenContent`
+ * builds its own [ConverterActions], so every test in the suite drove the stateless inner and none
+ * of them ever saw the wiring.
+ *
+ * Most of the list is safe without a test, and saying so is more useful than pretending otherwise:
+ * `onContainer`, `onVideoCodec`, `onAudioCodec`, `onPreset`, `onSuggestion`, `onQuality` and
+ * `onEnginePreference` each take a distinct type, so binding one to another's setter does not
+ * compile. Verified rather than assumed — swapping `onVideoCodec` and `onAudioCodec` fails with
+ * *"Inapplicable candidate(s): fun setAudioCodec(codec: AudioCodec)"*.
+ *
+ * **[ConverterActions.onCancel] and [ConverterActions.onReset] are the exception.** Both are
+ * `() -> Unit`, so swapping them compiles silently — also verified — and ships a Cancel button that
+ * throws the conversion away and a Start-over button that leaves it on screen. That pair is what
+ * `ConverterWiringTest` exists for.
+ *
+ * The three launcher-backed actions stay parameters: they need an `ActivityResultLauncher`, which
+ * is the part that genuinely needs the composition, and keeping them out means the rest can be
+ * checked without one.
+ */
+@UnstableApi
+internal fun converterActions(
+    viewModel: ConversionViewModel,
+    onPickInput: () -> Unit,
+    onConvert: () -> Unit,
+    onSave: (suggestedName: String) -> Unit,
+): ConverterActions = ConverterActions(
+    onPickInput = onPickInput,
+    onPreset = viewModel::setPreset,
+    onContainer = viewModel::setContainer,
+    onVideoCodec = viewModel::setVideoCodec,
+    onAudioCodec = viewModel::setAudioCodec,
+    onSuggestion = viewModel::applySuggestion,
+    onQuality = viewModel::setQuality,
+    onEnginePreference = viewModel::setEnginePreference,
+    onConvert = onConvert,
+    onCancel = viewModel::cancel,
+    onSave = onSave,
+    onReset = viewModel::reset,
+)
+
 /**
 * Everything [ConverterScreenContent] can ask for, in one value.
 *
@@ -56,17 +56,38 @@ fun JoinScreen(modifier: Modifier = Modifier, viewModel: JoinViewModel = viewMod

    JoinScreenContent(
        state = state,
-        actions = JoinActions(
+        actions = joinActions(
+            viewModel = viewModel,
            onPickInputs = { pickInputs.launch(arrayOf("video/*")) },
-            onJoin = viewModel::join,
-            onCancel = viewModel::cancel,
            onSave = { suggestedName -> chooseDestination.launch(suggestedName) },
-            onReset = viewModel::reset,
        ),
        modifier = modifier,
    )
 }

+/**
+ * Which of the ViewModel's methods each affordance on the join screen calls.
+ *
+ * The join-side twin of `converterActions`, and the transposition risk here is worse: **three**
+ * `() -> Unit` bindings rather than two. `onJoin`, `onCancel` and `onReset` are mutually
+ * interchangeable as far as the compiler is concerned, so a Join button that cancels, or a Cancel
+ * button that starts the job, is a swap nothing but a test would catch.
+ *
+ * See `converterActions` for why the launcher-backed actions stay parameters.
+ */
+@UnstableApi
+internal fun joinActions(
+    viewModel: JoinViewModel,
+    onPickInputs: () -> Unit,
+    onSave: (suggestedName: String) -> Unit,
+): JoinActions = JoinActions(
+    onPickInputs = onPickInputs,
+    onJoin = viewModel::join,
+    onCancel = viewModel::cancel,
+    onSave = onSave,
+    onReset = viewModel::reset,
+)
+
 /**
 * Everything [JoinScreenContent] can ask for, in one value.
 *