Write component tests that check behavior, not implementation details

You are writing tests for a React component using React Testing Library and Vitest. You test what a user can see and do, never internal state, prop values, or implementation details a user has no way to observe.

COMPONENT
A SearchableList component with a text input that filters a list of items client-side, and a "Clear" button.

KEY INTERACTIONS TO COVER
Typing in the search box filters the visible list to matching items; clicking Clear resets the input and shows the full list; typing something with no matches shows a "No results" message.

MOCKING BOUNDARY
Items are passed in as a prop in these tests — no network mocking needed for this component.

TESTING RULES
Query elements the way a real user would find them: getByRole, getByLabelText, getByText, in that rough order of preference. Only fall back to a test-id when there is genuinely no accessible way to find the element, and say so explicitly in a comment at that exact line when you do, since a test-id fallback is often a signal of a real accessibility gap in the component, not just a testing inconvenience. Never query or assert on component internal state, prop values, or CSS class names directly — if a behavior is worth testing, it is worth testing through what actually renders on screen or what happens when a user interacts with it. Use userEvent, not fireEvent, for every interaction, and always await it — userEvent's interaction methods are asynchronous by design to accurately simulate real browser event timing, and a missing await is the single most common cause of an intermittent, hard-to-reproduce flaky test in this exact stack. Write one test per meaningful behavior listed in the key interactions, named as a plain sentence describing the behavior — "shows an error when the field is left empty" — never as "test 1" or "renders correctly." Where the component does something conditionally, write both the positive case and the negative case explicitly; never test only the happy path and assume the conditional branch is covered by implication. Mock only at the exact boundary named above — a network call, a store — never by reaching into the component's internals to fake a piece of its own state. Avoid an arbitrary waitFor with a fixed timeout as a substitute for waiting on the actual condition that matters — prefer an assertion inside waitFor, or a query variant like findByRole, that resolves the moment the real DOM state changes, rather than a bare delay that either flakes on a slow CI machine or wastes time waiting past when the assertion could already have passed. When a test needs to wait for an element to disappear, use waitForElementToBeRemoved rather than polling queryBy* in a hand-written loop.

OUTPUT FORMAT
A complete test file, imports included, written for Vitest. Group related tests with describe blocks named after the feature being tested, not after the component's file name. If any test-id fallback was needed, list it separately at the end as a flagged accessibility gap worth fixing in the component itself.