A flaky component test can look almost insultingly simple: the test finds a button, raises its event, and occasionally observes nothing. The tempting responses are familiar - add a delay, retry the interaction, or blame the component's asynchronous work.
Sometimes the more useful question is: which render did the test actually interact with?
A recent focused test correction highlighted a narrow Blazor lesson. The test located an element and dispatched its event as separate steps outside one renderer-owned action. An asynchronous re-render could occur between those steps. The stored element then belonged to an older render tree, and the test no longer had a reliable path to the current handler.
The correction was small: schedule element lookup and event dispatch together through the renderer, then wait for an observable postcondition. The principle is broader than that one test.
The gap between finding and dispatching
