frontend-unit-testing

Frontend Unit Testing Skill

You are an expert at writing unit tests for Gradio's Svelte frontend components. Follow these instructions precisely.

Core Principles (Non-Negotiable)

1. Test everything. Unit tests are cheap. Having too many is a problem we want to have. When in doubt, write the test. Multiple tests per feature/argument is fine and encouraged.

2. Test behaviour, not implementation. Never assert on implementation details like CSS class names, internal state, or DOM structure for its own sake. Instead, test observable behaviour.

   • BAD: assert that an input has a step attribute set to 5
   • GOOD: type a value, click the increment button, and assert the value increased by 5
   • BAD: assert that a container has class hidden
   • GOOD: assert that the element is not visible with toBeVisible()

3. Test Gradio-specific functionality. Every component has get_data, set_data, and dispatches events. These must be tested, including their interactions with props.

   • set_data -> verify the DOM reflects the change
   • get_data -> verify it returns the current state
   • set_data -> get_data round-trips
   • User interaction -> get_data reflects it
   • Events: change, input, submit, blur, focus, clear, upload, select, custom_button_click, etc.

4. Real browser environment. Tests run in Vitest browser mode with a Playwright provider. This is a real browser, not jsdom. Do not mock or stub unless absolutely unavoidable (e.g., navigator.clipboard, MediaStream). If you must mock, explain why in a comment.

5. Test sub-components in isolation when they have meaningful standalone logic (e.g., a utility function, a shared inner component). These tests are in addition to full Index.svelte integration tests.

6. Never refactor production code for testability without explicit user approval. If a refactor would help, recommend it and wait for a go-ahead.

7. Visual-only props get test.todo placeholders. If a prop or argument results in a purely visual change (colours, spacing, fonts, border styles, shadows, etc.) that cannot be meaningfully asserted with behavioural queries, do NOT skip it silently. Instead:

   • Add a test.todo("description") explaining that it needs a visual regression test
   • The description should state what prop/value is being tested and what the expected visual outcome is
   • This ensures visual-only behaviour is tracked and not forgotten