Testing strategy for Supabase Studio. Use when writing tests, deciding what type of test to write, extracting logic from components into testable utility functions, or reviewing test coverage. Covers unit tests, component tests, and E2E test selection criteria.
apm install @supabase/studio-testing---
name: studio-testing
description: Testing strategy for Supabase Studio. Use when writing tests, deciding what
type of test to write, extracting logic from components into testable utility
functions, or reviewing test coverage. Covers unit tests, component tests,
and E2E test selection criteria.
---
# Studio Testing Strategy
How to write and structure tests for `apps/studio/`. The core principle: push
logic out of React components into pure utility functions, then test those
functions exhaustively. Only use component tests for complex UI interactions.
Use E2E tests for features shared between self-hosted and platform.
## When to Apply
Reference these guidelines when:
- Writing new tests for Studio code
- Deciding which type of test to write (unit, component, E2E)
- Extracting logic from a component to make it testable
- Reviewing whether test coverage is sufficient
- Adding a new feature that needs tests
## Rule Categories by Priority
| Priority | Category | Impact | Prefix |
| -------- | ---------------- | -------- | ---------- |
| 1 | Logic Extraction | CRITICAL | `testing-` |
| 2 | Test Coverage | CRITICAL | `testing-` |
| 3 | Component Tests | HIGH | `testing-` |
| 4 | E2E Tests | HIGH | `testing-` |
## Quick Reference
### 1. Logic Extraction (CRITICAL)
- `testing-extract-logic` - Remove logic from components into `.utils.ts` files
as pure functions: args in, return out
### 2. Test Coverage (CRITICAL)
- `testing-exhaustive-permutations` - Test every permutation of utility functions:
happy path, malformed input, empty values, edge cases
### 3. Component Tests (HIGH)
- `testing-component-tests-ui-only` - Only write component tests for complex UI
interaction logic, not business logic
### 4. E2E Tests (HIGH)
- `testing-e2e-shared-features` - Write E2E tests for features used in both
self-hosted and platform; cover clicks AND keyboard shortcuts
## Decision Tree: Which Test Type?
```
Is the logic a pure transformation (parse, format, validate, compute)?
YES -> Extract to .utils.ts, write unit test with vitest
NO -> Does the feature involve complex UI interactions?
YES -> Is it used in both self-hosted and platform?
YES -> Write E2E test in e2e/studio/features/
NO -> Write component test with customRender
NO -> Can you extract the logic to make it pure?
YES -> Do that, then unit test it
NO -> Write a component test
```
## How to Use
Read individual rule files for detailed explanations and code examples:
```
rules/testing-extract-logic.md
rules/testing-exhaustive-permutations.md
```
Each rule file contains:
- Brief explanation of why it matters
- Incorrect code example with explanation
- Correct code example with explanation
- Real codebase references
## Full Compiled Document
For the complete guide with all rules expanded: `AGENTS.md`
## Codebase References
| What | Where |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| Util test examples | `tests/components/Grid/Grid.utils.test.ts`, `tests/components/Billing/TaxID.utils.test.ts`, `tests/components/Editor/SpreadsheetImport.utils.test.ts` |
| Component test examples | `tests/features/logs/LogsFilterPopover.test.tsx`, `tests/components/CopyButton.test.tsx` |
| E2E test example | `e2e/studio/features/filter-bar.spec.ts` |
| E2E helpers pattern | `e2e/studio/utils/filter-bar-helpers.ts` |
| Custom render | `tests/lib/custom-render.tsx` |
| MSW mock setup | `tests/lib/msw.ts` (`addAPIMock`) |
| Test README | `tests/README.md` |
| Vitest config | `vitest.config.ts` |
| Related skills | `e2e-studio-tests` (running E2E), `vitest` (API reference), `vercel-composition-patterns` (component architecture) |