@jmruthers/pace-core 0.5.181 → 0.5.183

package/src/__tests__/TEST_STANDARD.md

@@ -1,1008 +0,0 @@
-# Testing Standard
-
-The authoritative guide for writing world-class tests in the pace-core project. Every test contribution should follow these standards to ensure reliability, maintainability, and comprehensive coverage.
-
-## 🎯 Testing Philosophy
-
-### Core Principles
-
-1. **Test Behavior, Not Implementation** - Focus on what users see and do, not internal code structure
-2. **Fast & Reliable** - Tests should run quickly and produce consistent results
-3. **Independent & Isolated** - Tests should not depend on each other or external state
-4. **Self-Documenting** - Tests should clearly express intent and expected behavior
-5. **Maintainable** - Tests should be easy to update when requirements change
-
-### The Testing Pyramid
-
-```
-    /\
-   /  \     E2E Tests (Few)
-  /____\    
- /      \   Integration Tests (Some)
-/________\  
-            Unit Tests (Many)
-```
-
-**Distribution Guidelines:**
-- **Unit Tests (80%)**: Fast, isolated tests for individual functions/components
-- **Integration Tests (15%)**: Test component interactions and data flow
-- **E2E Tests (5%)**: Full user journey validation
-
-## 🏗️ Test Organization
-
-### File Structure
-
-**✅ Preferred: Colocated Tests**
-```
-src/
-├── components/
-│   ├── Button/
-│   │   ├── Button.tsx
-│   │   └── Button.test.tsx          ✅ Next to source
-│   └── DataTable/
-│       ├── DataTable.tsx
-│       ├── DataTable.test.tsx       ✅ Main component tests
-│       └── __tests__/               ✅ For multiple test files
-│           └── DataTable.integration.test.tsx
-├── hooks/
-│   ├── useCounter.ts
-│   └── useCounter.test.ts           ✅ Colocated
-└── services/
-    ├── AuthService.ts
-    └── AuthService.test.ts          ✅ Colocated
-```
-
-**When to Use `__tests__/` Directory:**
-- Multiple test files for one source file (unit + integration)
-- Shared test utilities within a module
-- Integration tests spanning multiple components
-
-**Central `src/__tests__/` Directory - ONLY for:**
-- Cross-module integration tests
-- Shared test utilities and fixtures
-- Test configuration files
-
-### File Naming Conventions
-
-- `ComponentName.test.tsx` - Component tests
-- `hookName.test.ts` - Hook tests  
-- `serviceName.test.ts` - Service tests
-- `feature.integration.test.tsx` - Integration tests
-- `utils.unit.test.ts` - Utility function tests
-
-## 📝 Test Structure & Naming
-
-### Describe Block Organization
-
-```typescript
-describe('ComponentName', () => {
-  describe('Rendering', () => {
-    it('renders with default props', () => {});
-    it('renders with custom content', () => {});
-  });
-  
-  describe('User Interactions', () => {
-    it('handles click events', () => {});
-    it('handles keyboard navigation', () => {});
-  });
-  
-  describe('State Management', () => {
-    it('updates state on user input', () => {});
-    it('resets state on form submission', () => {});
-  });
-  
-  describe('Error Handling', () => {
-    it('displays error message on validation failure', () => {});
-    it('recovers from network errors', () => {});
-  });
-});
-```
-
-### Test Naming Best Practices
-
-```typescript
-// ✅ Good - Descriptive and behavior-focused
-it('renders submit button when form is valid', () => {});
-it('disables submit button when required fields are empty', () => {});
-it('shows loading spinner during form submission', () => {});
-
-// ❌ Bad - Vague or implementation-focused
-it('works correctly', () => {});
-it('test button component', () => {});
-it('should call onClick prop', () => {});
-```
-
-## 🧪 Testing Patterns
-
-### 1. Component Testing (AAA Pattern)
-
-```typescript
-describe('Button Component', () => {
-  it('handles click events with custom handler', async () => {
-    // Arrange
-    const handleClick = vi.fn();
-    const user = userEvent.setup();
-    
-    render(<Button onClick={handleClick}>Click me</Button>);
-    
-    // Act
-    await user.click(screen.getByRole('button', { name: 'Click me' }));
-    
-    // Assert
-    expect(handleClick).toHaveBeenCalledTimes(1);
-  });
-});
-```
-
-### 2. Hook Testing
-
-```typescript
-describe('useCounter Hook', () => {
-  it('initializes with provided value', () => {
-    const { result } = renderHook(() => useCounter(5));
-    
-    expect(result.current.count).toBe(5);
-  });
-  
-  it('increments count when increment is called', () => {
-    const { result } = renderHook(() => useCounter(0));
-    
-    act(() => {
-      result.current.increment();
-    });
-    
-    expect(result.current.count).toBe(1);
-  });
-});
-```
-
-### 3. Service Testing
-
-```typescript
-describe('AuthService', () => {
-  let mockSupabase: ReturnType<typeof createMockSupabaseClient>;
-  let authService: AuthService;
-  
-  beforeEach(() => {
-    mockSupabase = createMockSupabaseClient();
-    authService = new AuthService(mockSupabase);
-  });
-  
-  it('signs in user with valid credentials', async () => {
-    const mockUser = { id: '123', email: 'user@example.com' };
-    
-    mockSupabase.auth.signInWithPassword.mockResolvedValue({
-      data: { user: mockUser, session: {} },
-      error: null
-    });
-    
-    const result = await authService.signIn({
-      email: 'user@example.com',
-      password: 'password'
-    });
-    
-    expect(result.user).toEqual(mockUser);
-  });
-});
-```
-
-### 4. Integration Testing
-
-```typescript
-describe('User Registration Flow', () => {
-  it('completes full registration workflow', async () => {
-    const user = userEvent.setup();
-    
-    render(<RegistrationForm />);
-    
-    // Fill form
-    await user.type(screen.getByLabelText('Email'), 'user@example.com');
-    await user.type(screen.getByLabelText('Password'), 'password123');
-    
-    // Submit
-    await user.click(screen.getByRole('button', { name: 'Register' }));
-    
-    // Verify success
-    expect(await screen.findByText('Registration successful')).toBeInTheDocument();
-  });
-});
-```
-
-## 🔍 Query Best Practices
-
-### Semantic Queries (Preferred)
-
-```typescript
-// ✅ Excellent - Semantic and accessible
-screen.getByRole('button', { name: 'Submit' });
-screen.getByLabelText('Email address');
-screen.getByText('Welcome back');
-screen.getByPlaceholderText('Enter your name');
-
-// ✅ Good - Content-based
-screen.getByDisplayValue('current-value');
-screen.getByTitle('Close dialog');
-
-// ⚠️ Use sparingly - When semantic queries aren't sufficient
-screen.getByTestId('complex-widget');
-```
-
-### Query Priority Order
-
-1. **getByRole** - Most accessible and semantic
-2. **getByLabelText** - Form elements with labels
-3. **getByText** - Visible text content
-4. **getByDisplayValue** - Form elements with values
-5. **getByAltText** - Images with alt text
-6. **getByTitle** - Elements with title attribute
-7. **getByTestId** - Last resort for complex cases
-
-### Async Query Patterns
-
-```typescript
-// ✅ Good - Built-in waiting with findBy
-const button = await screen.findByRole('button', { name: 'Submit' });
-
-// ✅ Good - Wait for specific condition
-await waitFor(() => {
-  expect(screen.getByText('Data loaded')).toBeInTheDocument();
-});
-
-// ❌ Bad - Waiting for synchronous operations
-await waitFor(() => {
-  expect(result.current.count).toBe(0); // This is immediate!
-});
-```
-
-## 🔧 Mocking & Test Doubles
-
-### Mock Strategy
-
-```typescript
-// ✅ Good - Mock external dependencies only
-vi.mock('../api/users', () => ({
-  fetchUser: vi.fn().mockResolvedValue({ id: 1, name: 'John' })
-}));
-
-// ✅ Good - Mock complex external libraries
-vi.mock('react-router-dom', () => ({
-  useNavigate: () => vi.fn(),
-  useLocation: () => ({ pathname: '/test' })
-}));
-
-// ❌ Bad - Over-mocking internal utilities
-vi.mock('../utils/formatDate'); // Usually not necessary
-```
-
-### Multi-Call Mocking
-
-```typescript
-// ✅ Good - Handle different calls with mockImplementation
-mockSupabase.rpc.mockImplementation((functionName, params) => {
-  if (functionName === 'get_user') {
-    return Promise.resolve({ data: { id: '1' }, error: null });
-  }
-  if (functionName === 'get_permissions') {
-    return Promise.resolve({ data: permissions, error: null });
-  }
-  return Promise.resolve({ data: null, error: null });
-});
-```
-
-### Mock Isolation Best Practices
-
-**Problem**: Mocks can leak between test files, causing flaky tests.
-
-**Solutions**:
-
-```typescript
-// ✅ Good: Use vi.hoisted() for module mocks
-const { mockGetSignedUrl } = vi.hoisted(() => {
-  return {
-    mockGetSignedUrl: vi.fn(() => Promise.resolve({ url: 'test' }))
-  };
-});
-
-vi.mock('../utils/storage/helpers', () => ({
-  getSignedUrl: mockGetSignedUrl
-}));
-
-// ✅ Good: Reset mocks in beforeEach
-beforeEach(() => {
-  mockGetSignedUrl.mockClear();
-  mockGetSignedUrl.mockReset();
-  mockGetSignedUrl.mockImplementation(() => Promise.resolve({ url: 'test' }));
-});
-
-// ✅ Good: Use vi.spyOn for better isolation (when possible)
-const getSignedUrlSpy = vi.spyOn(storageHelpers, 'getSignedUrl');
-getSignedUrlSpy.mockResolvedValue({ url: 'test' });
-
-// ✅ Good: Use vi.stubGlobal for global mocks
-vi.stubGlobal('window', undefined);
-// Automatically restored after test
-
-// ❌ Bad: Directly modifying global objects
-delete global.window; // Can break other tests
-```
-
-**Mock Isolation Checklist**:
-- [ ] Use `vi.hoisted()` for module mocks
-- [ ] Reset mocks in `beforeEach`/`afterEach`
-- [ ] Use `vi.stubGlobal` for global mocks
-- [ ] Prefer `vi.spyOn` over `vi.mock` when possible
-- [ ] Test files in isolation to verify no leakage
-
-### Cleanup Best Practices
-
-```typescript
-describe('Component with Resources', () => {
-  beforeEach(() => {
-    vi.useFakeTimers();
-  });
-
-  afterEach(() => {
-    // Clean up timers
-    vi.clearAllTimers();
-    vi.useRealTimers();
-    
-    // React Testing Library cleanup
-    cleanup();
-    
-    // Clear all mocks
-    vi.clearAllMocks();
-    
-    // Clear storage
-    localStorage.clear();
-    sessionStorage.clear();
-  });
-});
-```
-
-## 🚫 Anti-Patterns to Avoid
-
-### 1. Testing Implementation Details
-
-```typescript
-// ❌ Bad - Testing internal state
-expect(component.state.isVisible).toBe(true);
-expect(wrapper.find('.hidden-class')).toHaveLength(0);
-
-// ✅ Good - Testing observable behavior
-expect(screen.getByText('Visible content')).toBeInTheDocument();
-expect(screen.queryByText('Hidden content')).not.toBeInTheDocument();
-```
-
-### 2. Skipped Tests Without Documentation
-
-```typescript
-// ❌ Bad - Skipped test without explanation
-it.skip('should navigate with keyboard', () => {});
-
-// ✅ Good - Skipped test with clear documentation
-// TODO: Enable when keyboard navigation is implemented
-// See: https://github.com/org/repo/issues/123
-// Expected: Q2 2025
-it.skip('should navigate with keyboard', () => {});
-```
-
-### 2. Brittle Selectors
-
-```typescript
-// ❌ Bad - Fragile and non-semantic
-screen.getByClassName('btn-primary');
-container.querySelector('.form > div:nth-child(2)');
-
-// ✅ Good - Semantic and stable
-screen.getByRole('button', { name: 'Submit' });
-screen.getByLabelText('Email address');
-```
-
-### 3. Testing Multiple Concerns
-
-```typescript
-// ❌ Bad - Too many assertions in one test
-it('renders form and validates and submits and shows success', () => {
-  // Multiple unrelated assertions
-});
-
-// ✅ Good - Single responsibility
-it('renders form with all required fields', () => {});
-it('validates email format on blur', () => {});
-it('submits form with valid data', () => {});
-it('shows success message after submission', () => {});
-```
-
-## 📊 Coverage Standards
-
-### Coverage Thresholds
-
-| Component Type | Target | CI Blocking | Rationale |
-|----------------|--------|-------------|-----------|
-| **Utils/Hooks** | 95% | Yes | Core business logic, high reuse |
-| **UI Components** | 90% | Yes | User-facing, must be reliable |
-| **Services** | 85% | Yes | API interactions, critical paths |
-| **Validation** | 95% | Yes | Security and data integrity |
-| **Overall Project** | 82% | Yes | Quality baseline |
-
-### What to Test
-
-- ✅ **Happy paths** - Normal user workflows
-- ✅ **Error conditions** - Network failures, validation errors
-- ✅ **Edge cases** - Empty states, boundary values
-- ✅ **User interactions** - Clicks, form submissions, navigation
-- ✅ **State changes** - Loading states, data updates
-- ✅ **Accessibility** - Keyboard navigation, screen reader support
-
-### What NOT to Test
-
-- ❌ **Third-party libraries** - Already tested by maintainers
-- ❌ **Generated code** - Auto-generated types, configs
-- ❌ **Pure styling** - CSS classes without behavior
-- ❌ **Type definitions** - Interfaces and type-only exports
-
-## 🔐 RBAC Testing Patterns
-
-### Provider Testing
-
-```typescript
-describe('RBACProvider', () => {
-  it('requires organisation context when configured', () => {
-    const { result } = renderHook(() => useRBAC());
-    
-    expect(() => result.current.requireOrganisationContext()).toThrow(
-      'Organisation context is required'
-    );
-  });
-
-  it('refreshes permissions when event changes', async () => {
-    const { result } = renderHook(() => useRBAC());
-    
-    act(() => {
-      result.current.setSelectedEventId('new-event-id');
-    });
-    
-    await waitFor(() => {
-      expect(result.current.rbacLoading).toBe(false);
-    });
-  });
-});
-```
-
-### Permission Hook Testing
-
-```typescript
-describe('useHasPermission', () => {
-  it('returns true when user has required permission', async () => {
-    setupRBACMock([
-      { permission_type: 'read:users', role_name: 'viewer' }
-    ]);
-    
-    const { result } = renderHook(() => 
-      useHasPermission('user-123', scope, 'read:users')
-    );
-    
-    await waitFor(() => {
-      expect(result.current.hasPermission).toBe(true);
-    });
-  });
-});
-```
-
-## 🎨 Component-Specific Patterns
-
-### DataTable Testing Strategy
-
-DataTable subcomponents intentionally have low unit test coverage because they're comprehensively tested through integration tests. This is **correct and intentional**.
-
-```typescript
-// ✅ Good - Integration test for DataTable workflows
-describe('DataTable - Complete Workflow', () => {
-  it('allows editing, sorting, and filtering data', async () => {
-    const user = userEvent.setup();
-    
-    render(<DataTable data={mockData} onSave={mockSave} />);
-    
-    // Test editing
-    await user.click(screen.getByRole('button', { name: 'Edit' }));
-    await user.type(screen.getByRole('textbox'), 'Updated Value');
-    await user.click(screen.getByRole('button', { name: 'Save' }));
-    
-    // Test sorting
-    await user.click(screen.getByRole('columnheader', { name: 'Name' }));
-    
-    // Test filtering
-    await user.type(screen.getByPlaceholderText('Filter...'), 'search term');
-    
-    expect(mockSave).toHaveBeenCalledWith(expectedData);
-  });
-});
-```
-
-### Service Hook Testing
-
-```typescript
-describe('useEventService', () => {
-  it('throws error when used outside provider', () => {
-    expect(() => {
-      renderHook(() => useEventService());
-    }).toThrow('useEventService must be used within EventServiceProvider');
-  });
-
-  it('subscribes to service updates and cleans up', () => {
-    const unsubscribe = vi.fn();
-    const mockService = {
-      subscribe: vi.fn(() => unsubscribe)
-    };
-
-    const { unmount } = renderHook(() => useEventService(), {
-      wrapper: ({ children }) => (
-        <EventServiceContext.Provider value={{ eventService: mockService }}>
-          {children}
-        </EventServiceContext.Provider>
-      )
-    });
-
-    expect(mockService.subscribe).toHaveBeenCalled();
-    
-    unmount();
-    expect(unsubscribe).toHaveBeenCalled();
-  });
-});
-```
-
-## ⚡ Performance & Memory
-
-### Memory Leak Prevention
-
-```typescript
-describe('Component with Async Operations', () => {
-  beforeEach(() => {
-    vi.useFakeTimers();
-  });
-
-  afterEach(() => {
-    // Prevent memory leaks
-    vi.clearAllTimers();
-    vi.useRealTimers();
-    cleanup();
-    vi.clearAllMocks();
-    localStorage.clear();
-    sessionStorage.clear();
-  });
-
-  it('handles cleanup properly', async () => {
-    // Test implementation
-  });
-});
-```
-
-### Async Testing Guidelines
-
-```typescript
-// ✅ Good - Appropriate timeouts based on operation speed
-await waitFor(() => {
-  expect(result.current.isLoading).toBe(false);
-}, { timeout: 100, interval: 10 }); // Fast operations
-
-await waitFor(() => {
-  expect(result.current.data).toBeDefined();
-}, { timeout: 2000 }); // Most async operations (2-3 seconds)
-
-// ⚠️ Only use 5+ seconds for truly slow operations
-await waitFor(() => {
-  expect(result.current.data).toBeDefined();
-}, { timeout: 5000 }); // Network calls, complex computations only
-```
-
-**Timeout Guidelines**:
-- **Fast operations** (< 100ms): `timeout: 100-500`
-- **Standard async** (100ms-2s): `timeout: 2000-3000`
-- **Slow operations** (2s+): `timeout: 5000+` (with documentation)
-
-**Avoid**:
-- ❌ Using 5-6 second timeouts for mock operations that resolve immediately
-- ❌ Using `waitFor` for synchronous operations
-- ❌ Unnecessary delays in mock implementations
-
-## 🔧 Test Configuration
-
-### Vitest Configuration
-
-```typescript
-// vitest.config.ts
-export default defineConfig({
-  test: {
-    environment: 'jsdom',
-    environmentOptions: {
-      jsdom: {
-        pretendToBeVisual: true, // Enables getComputedStyle
-        resources: 'usable'      // Enables resource loading
-      }
-    },
-    coverage: {
-      thresholds: {
-        lines: 82,
-        branches: 80,
-        functions: 80,
-        statements: 82
-      }
-    }
-  }
-});
-```
-
-### Test Utilities Setup
-
-```typescript
-// test-utils.tsx
-export function renderWithProviders(
-  ui: React.ReactElement,
-  options: { organisationId?: string } = {}
-) {
-  function Wrapper({ children }: { children: React.ReactNode }) {
-    return (
-      <OrganisationProvider organisationId={options.organisationId}>
-        <RBACProvider>
-          {children}
-        </RBACProvider>
-      </OrganisationProvider>
-    );
-  }
-  
-  return render(ui, { wrapper: Wrapper, ...options });
-}
-```
-
-## 🚀 Running Tests
-
-### Commands
-
-```bash
-# Run all tests
-npm test
-
-# Run with coverage
-npm test -- --coverage
-
-# Run specific test file
-npm test -- Button.test.tsx
-
-# Run tests in watch mode
-npm test -- --watch
-
-# Run tests with timeout (prevents hanging)
-timeout 60 npm test
-```
-
-### Debugging
-
-```typescript
-// Debug output
-screen.debug();
-
-// Debug specific element
-screen.debug(screen.getByRole('button'));
-
-// Log available queries
-screen.logTestingPlaygroundURL();
-```
-
-## 📋 Pre-Merge Checklist
-
-- [ ] All tests pass without `it.only` or `test.skip` (see Skipped Test Policy below)
-- [ ] Coverage thresholds are met
-- [ ] Tests use semantic queries (avoid test IDs)
-- [ ] Async operations use proper waiting patterns
-- [ ] Mocks are cleaned up in `afterEach`
-- [ ] Tests focus on behavior, not implementation
-- [ ] Error scenarios are covered
-- [ ] Tests are colocated with source files
-- [ ] Timeout values are appropriate (see Performance Guidelines below)
-
-## 🎯 Test Categories & Tags
-
-Use explicit tags for test organization:
-
-```typescript
-describe('[unit] useDebounce', () => {
-  it('delays function execution', () => {});
-});
-
-describe('[component] Button', () => {
-  it('renders with correct styling', () => {});
-});
-
-describe('[integration] User Registration', () => {
-  it('completes full signup flow', () => {});
-});
-```
-
-## 📚 Resources
-
-### Documentation
-- [React Testing Library](https://testing-library.com/docs/react-testing-library/intro/)
-- [Vitest Documentation](https://vitest.dev/)
-- [Jest DOM Matchers](https://github.com/testing-library/jest-dom)
-
-### Internal Guides
-- [Documentation Standard](../../docs/DOCUMENTATION_STANDARD.md)
-- [Memory Performance Analysis](../../../MEMORY_PERFORMANCE_ANALYSIS.md)
-- [Test Failure Analysis](../../../TEST_FAILURE_ANALYSIS.md)
-
----
-
-## 🎖️ Excellence Indicators
-
-A world-class test suite demonstrates:
-
-- **Comprehensive Coverage** - All critical paths tested
-- **Behavioral Focus** - Tests what users experience
-- **Maintainable Structure** - Easy to update and extend
-- **Fast Execution** - Quick feedback loops
-- **Clear Intent** - Tests serve as living documentation
-- **Reliable Results** - Consistent across environments
-- **Accessibility Awareness** - Tests include a11y considerations
-
-Remember: **Tests are not just about catching bugs—they're about building confidence, enabling refactoring, and documenting expected behavior for future developers.**
-
----
-
-## 🔄 Skipped Test Policy
-
-### When to Skip Tests
-
-**✅ Appropriate Reasons**:
-- Feature is planned but not yet implemented
-- Test documents future feature requirements
-- Feature is blocked by dependencies
-- Test is for experimental/optional feature
-
-**❌ Inappropriate Reasons**:
-- Test is flaky (fix the test instead)
-- Test is slow (optimize instead)
-- Feature is deprecated (remove test)
-- Test is temporarily broken (fix immediately)
-
-### Requirements for Skipped Tests
-
-1. **Clear Documentation**: Add comment explaining why test is skipped
-2. **Reference Tracking**: Link to feature issue or ticket
-3. **Expected Timeline**: Include expected implementation date (if known)
-4. **Quarterly Review**: Review skipped tests quarterly to determine if still relevant
-
-### Example
-
-```typescript
-// TODO: Enable when keyboard navigation is implemented
-// See: https://github.com/org/repo/issues/123
-// Expected: Q2 2025
-it.skip('should navigate between headers with arrow keys', async () => {
-  // Test implementation
-});
-```
-
-### Skipped Test Review Process
-
-1. **Quarterly Audit**: Review all skipped tests
-2. **Decision Matrix**:
-   - Feature implemented → Enable test
-   - Feature cancelled → Remove test
-   - Feature deferred → Update timeline
-   - Still relevant → Keep skipped with updated timeline
-3. **Documentation**: Update test comments with current status
-
----
-
-## 📊 Coverage Gap Remediation
-
-### Coverage Thresholds
-
-| Category | Target | CI Blocking | Rationale |
-|----------|--------|-------------|-----------|
-| **Utils/Hooks** | 95% | Yes | Core business logic, high reuse |
-| **UI Components** | 90% | Yes | User-facing, must be reliable |
-| **Services** | 85% | Yes | API interactions, critical paths |
-| **Validation** | 95% | Yes | Security and data integrity |
-| **Overall Project** | 80% | Yes | Quality baseline |
-
-### Identifying Coverage Gaps
-
-1. **Run Coverage Report**:
-   ```bash
-   npm test -- --coverage
-   ```
-
-2. **Review Coverage Report**:
-   - Check per-file coverage percentages
-   - Identify files below thresholds
-   - Review uncovered lines/branches
-
-3. **Prioritize Gaps**:
-   - **Critical**: RBAC, auth, services
-   - **High**: Business logic, hooks
-   - **Medium**: UI components, utilities
-   - **Low**: Type definitions, simple utilities
-
-### Remediation Process
-
-1. **Analyze Gap**: Understand what's not covered
-2. **Create Test Plan**: Determine test type (unit, integration)
-3. **Write Tests**: Follow TEST_STANDARD.md patterns
-4. **Verify Coverage**: Run coverage report to confirm improvement
-5. **Document**: Add comments for complex test scenarios
-
-### Coverage Improvement Checklist
-
-- [ ] Identify files below thresholds
-- [ ] Prioritize critical paths
-- [ ] Create test plan for each file
-- [ ] Write tests following TEST_STANDARD.md
-- [ ] Verify coverage improvement
-- [ ] Document complex test scenarios
-
----
-
-## ⚡ Performance Test Guidelines
-
-### Test Execution Time Targets
-
-- **Unit Tests**: < 50ms average
-- **Component Tests**: < 100ms average
-- **Integration Tests**: < 500ms average
-- **E2E Tests**: < 2s average
-
-### Timeout Best Practices
-
-**Standard Timeouts**:
-- Fast operations: `timeout: 100-500`
-- Standard async: `timeout: 2000-3000`
-- Slow operations: `timeout: 5000+` (with documentation)
-
-**Optimization Tips**:
-1. Use immediate mock resolution when possible
-2. Avoid unnecessary `setTimeout` in mocks
-3. Use `findBy` queries instead of `waitFor` + `getBy`
-4. Reduce timeout values for fast operations
-
-### Performance Testing Best Practices
-
-**When to Test Performance**:
-- ✅ Critical user-facing operations (rendering, navigation)
-- ✅ Operations that must complete within SLA
-- ✅ Memory-intensive operations
-- ❌ Avoid testing performance of mocked operations
-- ❌ Avoid absolute timing thresholds in CI environments
-
-**Performance Test Patterns**:
-
-```typescript
-// ❌ Bad: Absolute thresholds (brittle in CI/coverage)
-const startTime = performance.now();
-render(<Component />);
-const endTime = performance.now();
-expect(endTime - startTime).toBeLessThan(200); // Fails under coverage
-
-// ✅ Good: Behavioral assertions (focus on outcomes)
-await waitFor(() => {
-  expect(screen.getByRole('navigation')).toBeInTheDocument();
-}, { timeout: 2000 });
-
-// ✅ Good: Relative comparisons (more tolerant)
-const baseline = measureBaseline();
-const actual = measureActual();
-expect(actual).toBeLessThan(baseline * 1.5); // 50% tolerance
-
-// ✅ Good: Smoke tests (verify no regressions)
-it('renders without performance degradation', async () => {
-  const startTime = performance.now();
-  render(<Component />);
-  await waitFor(() => {
-    expect(screen.getByRole('main')).toBeInTheDocument();
-  });
-  const endTime = performance.now();
-  // Only fail if significantly slower (e.g., > 5s)
-  expect(endTime - startTime).toBeLessThan(5000);
-});
-```
-
-**Performance Test Guidelines**:
-1. **Prefer Behavioral Tests**: Focus on what users see, not raw timing
-2. **Use Relative Thresholds**: Compare against baseline, not absolute values
-3. **Skip in Coverage Mode**: Use `if (process.env.COVERAGE) return;` for timing tests
-4. **Document Thresholds**: Explain why specific timing is critical
-5. **Separate Performance Suite**: Consider separate test suite for performance tests
-
-### Memory Management
-
-```typescript
-describe('Component with Resources', () => {
-  beforeEach(() => {
-    vi.useFakeTimers();
-  });
-
-  afterEach(() => {
-    // Prevent memory leaks
-    vi.clearAllTimers();
-    vi.useRealTimers();
-    cleanup();
-    vi.clearAllMocks();
-    localStorage.clear();
-    sessionStorage.clear();
-  });
-});
-```
-
-### Performance Monitoring
-
-- Monitor test execution times in CI
-- Track slow tests (> 100ms)
-- Alert on tests exceeding thresholds
-- Review and optimize slow tests regularly
-
----
-
-## 📁 Large Test File Management
-
-### When to Split Test Files
-
-**Consider Splitting When**:
-- File exceeds 800 lines
-- File contains multiple distinct feature areas
-- File has slow execution times
-- File is difficult to navigate
-
-### Splitting Strategy
-
-**By Feature Area**:
-```
-Component.test.tsx          → Component.rendering.test.tsx
-                            → Component.interactions.test.tsx
-                            → Component.state.test.tsx
-```
-
-**By Test Type**:
-```
-Component.test.tsx          → Component.unit.test.tsx
-                            → Component.integration.test.tsx
-                            → Component.accessibility.test.tsx
-```
-
-### Splitting Guidelines
-
-1. **Keep Related Tests Together**: Don't split if tests are tightly coupled
-2. **Maintain Test Organization**: Use describe blocks for organization
-3. **Share Test Utilities**: Extract shared setup to test utilities
-4. **Document Structure**: Add README explaining test organization
-
-### File Size Recommendations
-
-- **< 500 lines**: No splitting needed
-- **500-800 lines**: Consider if organization improves
-- **> 800 lines**: Strongly consider splitting
-- **> 1000 lines**: Should be split
-
----
-
-## 📈 Continuous Improvement
-
-### Regular Reviews
-
-1. **Quarterly**: Review skipped tests, coverage gaps, slow tests
-2. **Monthly**: Review test execution times and patterns
-3. **Per PR**: Ensure new tests follow TEST_STANDARD.md
-
-### Metrics to Track
-
-- Test execution time trends
-- Coverage percentage trends
-- Number of skipped tests
-- Test helper usage patterns
-- Test file sizes
-
-### Resources
-
-- [Coverage Gap Analysis](../../docs/testing/coverage-gap-analysis.md)
-- [Test Quality Audit](../../docs/testing/test-quality-audit.md)
-- [Test Helpers Audit](../../docs/testing/test-helpers-audit.md)
-- [Skipped Tests Analysis](../../docs/testing/skipped-tests-analysis.md)