In a component test of a parent, how do you trigger an event a child component emits, and what should you assert?

## A component output is not a host event When a parent listens for something a child announces, the wiring is the framework's own: the child is handed a callback, or the framework registers the parent's handler against the child's declared output and invokes it when the child emits. That channel lives above the host tree. Dispatching a host event of the same name on the child's root node therefore does not reach the parent's handler - there is no host listener there to catch it - unless the child was deliberately built to re-dispatch its output as a host event as well. This is the first thing to get right in a parent's test, because the symptom is a silent nothing: the dispatch succeeds, no handler runs, and the assertion fails with no clue about which layer swallowed it. ## The two seams, and what each buys | | Real child, driven through its own control | Stub child that emits | |---|---|---| | What the test does | put a value on the child's control, dispatch its binding's event | call the output the stub was handed, with a chosen payload | | What it proves | the whole path: child binding, emit, parent handling | the parent's handling, given a payload | | What it misses | little, but it is slow and broad | that the real child ever emits, and with that shape | | Breaks when | the child's internal markup changes | the child's output contract changes silently | | Best for | a small, stable child the parent is meaningless without | a heavy child, or many payload cases | The honest way to use the second column is to pair it with a **contract test on the child itself**: the child's own test proves it emits the output with that payload when driven, and the parent's test proves what it does with such a payload. Together they cover the path the first column covers in one go. Without the child's test, a stub child lets the two halves drift until nothing emits and every test is green. ## What to assert in the parent Assert on the parent's observable response, not on the mechanics of the call: - the parent's rendered output changed in the way the payload implies - the selected row highlighted, the summary recalculated, the panel opened on that item; - the parent's own upward output carries the right value, when it forwards a transformed payload to its own parent; - a collaborator the test supplied received the expected argument, when handling means issuing a command; - the payload's **shape** was read correctly: a parent that expects a plain value but receives an object, or reads a field the child does not emit, fails here and nowhere else. What not to assert: that the stub's emitter was called. The test itself called it, so that assertion is circular in exactly the way reading back a value you wrote is. ## Payload shape is where parents actually break The most common real defect at this seam is not a missing handler but a mis-read payload. A child emits a value; the parent's handler is written as though it received a host event and reaches for a property that is not there. Or the child emits an object with the item and its index, and the parent reads only the index and then indexes a filtered array. Tests that assert "the handler ran" never see either bug. Tests that assert on rendered output from a realistic payload see both immediately, which is why the payload used in the test should be the shape the child really emits - copied from the child's contract, not invented. ## Ordering and settling An emit is a state write in the parent, so the same discipline applies as for a host-event binding: after triggering the output, let the framework settle before asserting on rendered output. Under a runtime that re-runs the component function the parent re-derives its subtree; under a fine-grained runtime only the subscribers of the changed value are notified; under a compile-time runtime the generated invalidation runs. In all three, the assertion belongs after the settle, and a missing settle looks confusingly like a handler that never ran. ## Choosing between the seams in practice 1. If the child is small, stable, and the parent's behaviour is meaningless without it, drive the real child. The extra coverage is nearly free and the coupling is honest. 2. If the child is heavy, owns its own suite, or the parent needs a dozen payload cases, stub it and trigger the output directly - then check the child's suite really pins the contract. 3. If the child comes from outside the codebase, prefer the stub and keep one broader test that exercises the real thing, so an upstream contract change is not invisible. 4. Whichever seam you pick, name it in the test so the next reader knows what the green result covers.