After driving a bound field in a component test, when is reading the element's own value back a circular assertion?

## The read-back is the test's own echo One interaction step in a component test is: put a value on the host control, dispatch the host event the binding is registered for, let the framework settle, assert. The tempting fourth step is to read the control's `value` and check it - and that is the step that can be circular, because the value came from the test. Three outcomes all produce the same green: - the listener ran, state was written, and a render wrote the same text back to the control; - the listener never ran, nothing re-rendered, and the text the test wrote is still sitting on the element; - the framework has no binding on that control at all. An assertion that cannot distinguish those three is not testing the component. ## When the value is re-rendered from state If the control's value is written from state on every cycle, the round trip only shows up in output that is **derived** from state. Good targets: - a live character or item count rendered in a sibling node; - a validation message, or its absence; - an enabled or disabled action control that depends on the field; - a formatted echo of the value elsewhere - a preview, a summary line; - the argument passed to a callback the test supplied from above. Each of those is unreachable unless the listener ran and the update was applied, so each one fails for the right reason. ## When the control owns its own value If the component never mirrors the field into state and simply reads the control when it needs it, the element **is** the source of truth. Reading it back then tests the host platform's property, which was never in doubt. The assertion has to move to the moment the component reads: collect the form's data on submit and assert the payload; or assert on the handler's argument if the component hands the value to a callback. For that shape, a dispatch of the per-keystroke event is often unnecessary - what matters is that the value is on the control before the read happens, and that the read-triggering event is dispatched. ## The two shapes side by side | | Value re-rendered from state | Control owns the value | |---|---|---| | What the test writes | the control's `value` | the control's `value` | | What it dispatches | the event the binding listens on | the event that triggers the read (often submit) | | Where it asserts | output derived from state | the collected payload or the handler's argument | | The false pass | the written text is still on the element | the platform stored the value, as it always would | | What a real failure looks like | derived output stale | payload missing or mis-keyed the field | ## The confusing inverse: the field snaps back The mirror-image bug is worth recognising. When a field's value is rendered from state and the binding does **not** write state - a missing handler, a value bound one way only - the control keeps the test's text until the next render, and then that render writes state's old value back over it. So the same test can look green early and red later, depending on whether anything else in the test caused a render. That flicker is a real product bug (a user's keystrokes vanish), and a test that asserts only on the control's own value is precisely the test that cannot decide whether it happened. ## Framework differences, same rule What triggers the overwriting render varies. A runtime that re-runs the component function re-derives the whole subtree and reconciles the control's value against state on each pass; a fine-grained runtime touches the control only when the value it subscribes to changes, so a missing write may leave the stale text on screen much longer; a compile-time runtime does whatever its generated invalidation says. None of that changes the assertion rule - it only changes how long the false green survives, which is why leaning on the control's value makes tests behave differently across frameworks for no good reason. ## A practical recipe 1. Decide, before writing the assertion, whether state or the control owns the field's value in this component. 2. Pick an assertion target that only the owner's path can produce. 3. If the only observable output **is** the control's value, add one: a count, a preview, a disabled flag, or a callback the test can watch. A component with no output derived from a field is hard to test because it is hard to observe, and that is design feedback. 4. Keep one read-back assertion only where the point of the test is that the control displays what state holds - and then write the value into state from above rather than typing it, so the assertion is not reading its own input. That last case is the honest use of a read-back: the test supplies state, the framework renders, and the control's value is genuinely the output under test.