Svelte Test Processor

Create comprehensive tests for Svelte components and SvelteKit routes including unit tests, component tests, and E2E tests with proper mocking and assertion patterns.

When to Use This Command

Run this command when...

• You need to write thorough tests for a Svelte component covering rendering, user interaction, accessibility, and edge cases
• You want tests for SvelteKit routes including load functions, form actions, and server-side logic
• Your component has complex behavior like async data fetching, store subscriptions, or conditional rendering that needs systematic test coverage

Do NOT use this command when...

• Testing infrastructure is not set up -- use the test setup command first
• Your tests are failing -- use the test fix command to diagnose and repair

Quick Start

Copy
# .claude/commands/svelte-test-processor.md
# Create Svelte tests
Create tests for: $ARGUMENTS

Copy
# Run the command
claude "svelte-test-processor write component tests for SearchInput with debounced API calls and result display"

Expected output:
- SearchInput.test.ts with rendering tests
- User interaction tests (type, clear, submit)
- Debounce behavior verification with fake timers
- API mock setup and response handling
- Accessibility assertions for ARIA attributes

Core Concepts

Concept	Description
Component Rendering	Mounting Svelte components with props and asserting DOM output
User Event Simulation	Firing click, type, and keyboard events with @testing-library
Async Testing	Handling reactive updates, API calls, and timers with await and tick
Store Testing	Testing Svelte stores independently and within subscribed components
Route Testing	Testing SvelteKit load functions and form actions in isolation

Test Coverage Matrix:

  Component Under Test
       |
  +----+----+----+----+
  |    |    |    |    |
 Render Props Events Async A11y
  |    |    |    |    |
  [Assertions]
  |    |    |    |    |
 DOM   Prop  Handler Promise ARIA
 Match Update Called  Resolve Attrs
       |
  Coverage Report

Configuration

Parameter	Default	Description
Test Type	Component	Unit, component, integration, or E2E test generation
Coverage Target	Behavioral	Whether to target line coverage or behavioral coverage
Mock Strategy	Minimal	Mock only external dependencies vs mock aggressively
Assertion Style	testing-library queries	getByRole/getByText vs querySelector-based assertions
Async Handling	Auto-detect	Whether to use fake timers, waitFor, or manual tick control

Best Practices

1. Test behavior, not implementation -- assert what the user sees and can do rather than internal component state. Query by role and text, not by CSS class or component internals
2. Use getByRole as your primary query -- it tests accessibility implicitly. If you cannot find an element by role, the component may have an accessibility problem
3. Handle Svelte reactivity explicitly -- after triggering state changes, await tick() or use waitFor() to let reactive updates propagate before asserting
4. Mock at the boundary -- mock API calls and external services, not internal functions. This gives confidence that component integration works correctly
5. Test edge cases explicitly -- empty states, error responses, loading states, and boundary values catch bugs that happy-path tests miss

Common Issues

1. Reactive updates not reflected in assertions -- add await tick() after state changes or use waitFor() to poll until the DOM reflects the expected state
2. Event handlers not called -- use await fireEvent rather than fireEvent alone. Svelte event handling may require microtask completion before effects run
3. Store subscriptions cause memory leaks in tests -- call cleanup() in afterEach to unmount components and unsubscribe stores between tests