What this prompt does
This prompt has the model act as a senior Vue/TypeScript engineer and write tests for a specific component, [component_name], using Vitest and @testing-library/vue, returning working tests rather than pseudocode. You set the [component_name], the [render_mode], and the [states] to cover, and it returns the setup config plus an example test file covering rendering, interaction, emitted events, and accessibility.
The structure works because the tests that survive refactors assert on roles and visible text, not internal component state. By covering every state in [states], driving interactions through userEvent, asserting on emitted event payloads, and adding accessibility assertions for roles, labels, and focus, the prompt produces behavior-focused tests. [render_mode] controls how the component mounts, and test data is built as factories so cases stay readable. Querying by accessible role gives you a useful side effect: the same assertions that verify behavior also catch accessibility regressions, so you cover two concerns in a single pass.
When to use it
- You're testing a Vue 3 component and want behavior-focused, refactor-resilient tests.
- You need to cover loading, error, empty, and content states explicitly.
- You want user interactions driven through
userEvent, not internal calls. - You need assertions on emitted events and their payloads.
- You want accessibility checks on roles, labels, and focus in the same pass.
- You want a clean Vitest + jsdom + Testing Library setup config.
- You want a test template the rest of your components can follow.
Example output
Expect two separate code blocks: the setup config (Vitest + jsdom + testing-library) so the suite runs cleanly, and a single example test file for [component_name]. The test file covers rendering for each state in [states], user-interaction tests via userEvent asserting on what the user sees, emitted-event assertions with payloads, and accessibility assertions for roles, labels, and focus — with test data built as factories and the component mounted [render_mode]. The two blocks are separated so you can drop the config in once and reuse the test file as the template every other component's suite follows.
Pro tips
- Query by accessible role wherever you can; it tests behavior and catches a11y regressions in the same pass.
- List
[states]explicitly (e.g. loading, error, empty, content) so every branch of the component gets a rendering test. - Set
[render_mode]to match your strategy (e.g. shallow with stubbed children) so tests isolate the component you care about. - Assert on visible text and emitted payloads, not internal state, so tests survive refactors.
- Use the factory pattern for test data so cases stay readable as you add more of them.
- Name
[component_name]exactly as in your codebase so the imports and selectors in the generated test are correct.
