If a component test should assert only what a user can perceive, how do you test a component whose job is to invoke an `onSubmit` prop and send a request — outputs a user never sees on screen?

## Restating the rule correctly The slogan "test behavior, not implementation" gets compressed into "only assert what renders", and that compression is wrong. The precise line is **observable from outside the component** versus **internal to it**. Rendered output is the most common outward observation, but it is not the only one. A component has three kinds of outward effect: 1. **What it renders** — text, controls, states a user perceives. 2. **What it calls** — callback props the parent handed it (`onSubmit`, `onChange`, `onClose`), navigation it triggers. 3. **What it sends** — requests that leave the process entirely. All three are visible to somebody outside the component: the user, the parent, the server. All three are legitimately assertable. What is *not* assertable is the path between the interaction and the effect — which internal handler ran, what state was set on the way, how many renders it took. ## Drive from the interaction, assert at the boundary The shape of a good test for an outward effect is always the same: - **Arrange** — render the component with a spy in place of the real callback, or with the network boundary faked. - **Act** — do what a user does. Type into the field found by its label, click the button found by its visible name. Not: grab the form node and dispatch a raw submit; not: call the prop yourself. - **Assert** — the callback was invoked, once, with the payload derived from what the user typed. Or: a request was sent with that body. That structure is what makes the assertion refactor-proof. The component can move from a controlled input to an uncontrolled one, from a hand-rolled form to a form library, from one state container to another — the test still passes, because the entry point (a user typing and clicking) and the exit point (a callback carrying the typed values) are both unchanged. ```javascript const onSubmit = jest.fn(); render(<NewsletterForm onSubmit={onSubmit} />); await userEvent.type(screen.getByLabelText('Email'), '[email protected]'); await userEvent.click(screen.getByRole('button', { name: 'Subscribe' })); expect(onSubmit).toHaveBeenCalledTimes(1); expect(onSubmit).toHaveBeenCalledWith({ email: '[email protected]' }); ``` Every element of that test corresponds to something real: a user with an email address, a button they can see, a parent that receives the value. ## Why calling the prop directly is the wrong shortcut It is always tempting to skip the typing and clicking and just invoke the handler. Two things break. First, you stop testing the wiring. If the button is never connected to the handler, if it is `disabled` when it should not be, if the form swallows the submit — the direct-invocation test is green and the product is broken. The interaction *is* part of the behavior. Second, you couple to the handler's identity and signature, which is exactly the internal shape most likely to change during a refactor. ## Asserting the call, not just that it happened "It was called" is a weak assertion. Three properties are usually worth pinning down, because each corresponds to something a user would notice: - **The payload** — the values the user actually entered, in the shape the parent expects. A wrong payload means their data is lost. - **The call count** — exactly once. A double-fire on submit is a real, user-visible defect (duplicate orders), and counting the calls is not a render-count assertion; it is counting an outward effect. - **The absence of a call** — when validation fails, nothing should be submitted. That negative assertion is often the more valuable one. ## Where the request boundary fits When the component sends the request itself rather than delegating to a prop, the same principle applies one layer out: the seam belongs at the network boundary, and the assertion is about what crossed it. That keeps the test indifferent to whether the component uses one HTTP client or another, or restructures how it builds the call. Note the direction of the tradeoff — a callback prop is the cheapest, most stable boundary available, so when a component already delegates to a prop, assert there rather than reaching further out. ## The mistake to name in an interview The two failure modes sit on opposite sides. One candidate refuses to assert anything but rendered text and therefore never verifies that the form submits at all. The other asserts internal handlers and state updates and calls it "testing the submit logic". The correct position is in between and it is precise: **drive the component the way a user does; observe it the way its collaborators do; never observe it the way its own source code does.**