A bound control's value cannot be written from a test - a file picker, for instance. How do you still cover the binding?

## Why some bound controls cannot be written Driving a binding normally means placing a value on the control and dispatching the host event the binding listens on. Some controls refuse the first half: - **The platform protects the control.** A file picker's value may not be set to a path by script - only cleared - because that would let a page read files the user never chose. The write throws or is ignored, and the test cannot pretend otherwise. - **The payload is not a string on the element.** What the binding reads is a list of selected files, a range within a text region, a structure a wrapped widget owns internally. There is no scalar property to assign. - **The value only exists at commit.** The component never mirrors the control into state; it collects the values when the form is submitted, so there is nothing to observe between the write and the commit. ## The ladder, in order of preference 1. **Use the platform's own supply route.** Where the platform provides a constructible carrier for the payload - a transfer object that can hold a file list, for example - build the payload with it, attach it where the binding reads it, and then dispatch the commit event the binding is registered for. This is a genuine interaction test: the real binding runs on real data. 2. **Call the component's own handler with a realistic payload.** The binding's job is to hand the control's payload to a function. Call that function directly with a payload shaped like the real one, settle, and assert the state and rendered output it produces. Everything after the binding is covered; the binding itself is one untested line, and that is a truthful trade. 3. **Push the last mile out.** A real pick in a real control belongs to the layer that drives a real browser, and that layer owns it. Do not simulate it badly in a component test; record the gap and cover it where it can be covered honestly. 4. **Make the untestable surface thin.** If the control is wrapped in a small component whose only job is to turn the platform's payload into a plain value and announce it, then the rest of the tree is testable against that plain contract, and only the wrapper carries the heavy test. ## What not to do The tempting shortcut is to write the component's state directly to the value the control would have produced and call it an interaction test. That asserts the framework can render state, which was never in question, and it skips the handler under test - the one place the payload is decoded. The difference between this and step 2 is precise: step 2 calls the component's own decoding path with a realistic payload; the shortcut jumps over it. The other shortcut is to assert on markup - that the control was rendered with the right accepted types or a multiple flag - and stop. That is worth one small assertion, but it is a rendering test, not an interaction test, and a suite made of those goes green while the payload handling is broken. ## Controls and routes | Control | Why the write fails | What the test does instead | |---|---|---| | File picker | platform allows only clearing the value | build the payload with the platform's carrier, then dispatch the commit event | | Editable region | the content is a tree, not a scalar property | call the change handler with the content the component expects | | Wrapped third-party widget | the value lives inside the widget | test the wrapper's contract; drive the widget in the browser layer | | Read only at submit | nothing observable before the commit | place values, dispatch the submit-triggering event, assert the collected payload | ## Say what is not covered A test that stops short should say so in its name or a one-line comment: "handles a chosen file's payload (the pick itself is covered in the browser layer)". That sentence is what stops a future reader from believing the picker is proven, and it is what makes the gap visible to whoever owns the broader suite. A silent gap is worse than a declared one, because the declared one gets scheduled. ## The framework-neutral part None of this depends on the reactivity model. The binding is still a listener; the payload is still read when its event fires; the update is still queued and must be settled before output is asserted. What differs is only how much of the path the test can reach, and the answer is always the same shape: get as close to the real entry point as the platform allows, and be explicit about the last step you could not take. ## A sanity check before you accept the compromise Ask whether the untestable surface is untestable by nature or by design. A component that reads the platform's payload deep inside a large handler is hard to test because it is entangled, not because the platform forbids anything. Extracting the decode into a small function with a plain input and a plain output turns most of this problem into an ordinary unit test and leaves a single line of genuinely platform-bound code behind.