Testing Library prompts help an agent describe a component in terms of what someone can see and do. That might mean correcting an invalid email, opening a menu with a keyboard, or learning that a save failed. The useful question is whether the interface communicates the right result. A test that only inspects an internal state value can miss a form that leaves the person unable to continue.
Describe the interaction and its boundary
Provide the component, one existing test, runner configuration and any shared render helper. Explain which providers the component needs and which network boundary the test controls. Do not ask the agent to rebuild application infrastructure just to test a label. The Testing Library guiding principles emphasize DOM interactions that resemble how software is used. The prompts here apply that idea to practical review tasks.
Write down the starting state and the expected end state. Include focus only when it is part of the interaction contract, such as returning focus after closing a dialog. Keep uncertain behavior visible as a question for the product owner.
Test a form people can correct
A form test should show what happens after the first mistake. A submission rejection may leave values intact, identify the affected field and allow a successful second attempt. Those transitions are more informative than a test that merely finds a submit button. Supply the exact validation copy when the wording itself is part of the requirement.
Write Testing Library tests for {{form_component}} using {{example_test}}.
Cover initial state, {{invalid_input}}, a server rejection and a corrected
successful submission. Query the rendered interface by accessible names
where practical. Check the visible error and preserved values.
Use the project's interaction helper and await resulting UI changes.
Do not assert private component state or CSS implementation details.
Check loading, empty and failed responses separately
These states have different meanings. An empty list can be a successful response; a failed request needs a recovery path. Ask the agent to control when the request resolves so the loading state is observable. Otherwise a fast fixture can skip the transition the test was supposed to protect.
Test response states in {{component_path}}.
Control {{request_boundary}} to produce loading, empty success, populated
success and failure. For each case, state what the person should see and
which action remains available. Verify retry behavior after failure.
Keep the mock at the request boundary and preserve the real rendering.
Review keyboard behavior without overclaiming coverage
A keyboard test is valuable when the component owns focus movement or activation. Describe how it should open, close and return focus. Do not assume an arbitrary key is standard for a custom widget. Compare the requested behavior with the component's established pattern, then verify it in the relevant environment.
Review keyboard behavior for {{widget}} in {{component_path}}.
Use {{interaction_contract}} as the expected behavior. Test opening,
activation, dismissal and focus return where applicable. Identify anything
our DOM environment cannot establish and give a short browser check for
it. Do not describe these tests as a complete accessibility audit.
Keep tests understandable after the UI evolves
Read the assertions alongside a screenshot or the rendered page. Their names should describe a state someone recognizes. If a selector breaks after a harmless markup change, investigate whether the test was coupled to structure. If a label change breaks it, decide whether that change is meaningful before updating the assertion.
Save your approved interaction recipe in Kipt with variables for component, boundary and expected copy. For journeys across several pages or real browser behavior, use the Playwright prompts alongside these component-focused checks.