Why can a component test that drives a bound field with the commit event pass while the per-keystroke behaviour it claims to cover is broken?

## Two different components, one passing test Consider a field with a live character counter next to it. Two implementations are possible: - a **live binding**, which reads the control on every per-keystroke event and writes state each time; - a **lazy binding**, which reads the control only when the edit is committed - the field loses focus, or the user confirms it. Only the first satisfies "the counter updates as I type". Now consider a test that places text on the control, dispatches the **commit** event, settles, and asserts the counter reads 3. Against the live binding it passes. Against the lazy binding it **also** passes, because the commit event is exactly what that binding listens on. The test is green and the feature is broken in the browser, where the counter sits at 0 until the user tabs away. ## The asymmetry that makes this a silent failure | Component binds on | Test dispatches | Outcome | |---|---|---| | per-keystroke event | per-keystroke event | passes, and proves the live requirement | | commit event | per-keystroke event | **fails loudly** - the listener never ran | | per-keystroke event | commit event | passes, but proves nothing about typing | | commit event | commit event | passes, and proves only the lazy behaviour | Read the third row: it is the only combination that is both green and uninformative. That is why the later event is called **permissive** - it cannot distinguish the two implementations - and the earlier one **strict**. Failures from a strict dispatch are cheap: a developer sees red and fixes the test or the component within minutes. Failures from a permissive dispatch are expensive, because nothing ever goes red. ## Finding out which event the binding is actually registered for 1. **Read the binding's declaration.** Frameworks encode this in the binding syntax: a default value binding on a text field almost always registers for the per-keystroke event, and the lazy or commit-only behaviour is an explicit opt-in on the binding. Boxes, menus and date pickers are commonly bound on the commit event instead, because that is the only event the platform gives for a pick. 2. **Inspect the mounted node.** A harness that can enumerate the listeners attached to a control answers the question directly, with no guessing. 3. **Probe empirically.** Dispatch one event, settle, and look at the derived output; then the other. Exactly one of them should move the output under test. If both do, the component is listening on both and the test should say so. ## Dispatch the narrowest event the requirement implies - "The counter updates while I type" -> the per-keystroke event **alone**, with no commit event after it. - "The error appears when I leave the field" -> value in place, then the focus-leaving event, and assert the message was **absent** before it. - "The list filters when I pick an option" -> the commit event on the picker, because that is the only event the control produces. - "The form submits what I typed" -> a submit-shaped dispatch, and assert on the collected payload rather than on intermediate state. The negative assertion in the second case is what turns a permissive test strict: proving the message is not there yet is what fails when the field validates eagerly. ## Helpers that fire a sequence for you A helper that imitates a real user typically dispatches several events per interaction - one per character, and the commit event when focus leaves. Such a test is not wrong; it is **permissive** by construction, and it is a good approximation of the user's whole gesture. The mistake is treating it as coverage of the per-keystroke requirement. Keep it, and add one narrow test that dispatches only the per-keystroke event where the requirement says "while typing". ## Why the settle hides the seam further After the correct dispatch, derived output is stale until the framework drains its update queue, so an over-eager assertion fails for a reason that looks identical to a wrong-event dispatch: state did not move. Get into the habit of separating the two questions - did the listener run, and has the update been applied - because the fix is different in each case. Under a runtime that re-runs the component function, a fine-grained runtime that notifies one value's subscribers, and a compile-time runtime that pairs the assignment with an invalidation, the settle differs in mechanism but the ordering discipline is the same. ## What a good test records The test's name should say which event it drove, because that name is the documentation of the requirement: "updates the counter on each keystroke" is a different test from "validates when the field is left". When both requirements are real, they are two tests with two dispatches, not one test with a sequence that satisfies whichever binding happens to exist.