# Coverage Remediation Plan v2.0 - Path to 90% Coverage

## Executive Summary

This document outlines a comprehensive 4-week plan to achieve 90%+ test coverage across the `leptos-shadcn-ui` repository, focusing on the three critical areas identified in our analysis:

1. **Component Implementation Tests** (currently 23-30% coverage)
2. **Signal Management Coverage** (currently 0%)
3. **Infrastructure Utilities** (currently 0%)

## Current Coverage Status

### Baseline Metrics (from llvm-cov analysis)
- **Overall Coverage**: 62.5% (1,780/2,847 lines)
- **Target Coverage**: 90%+ (2,562+ lines)
- **Gap to Close**: 782+ lines of coverage

### Critical Coverage Gaps
| Area | Current Coverage | Target Coverage | Lines to Cover |
|------|------------------|-----------------|----------------|
| Component Implementations | 23-30% | 85%+ | ~400 lines |
| Signal Management | 0% | 80%+ | ~200 lines |
| Infrastructure Utilities | 0% | 75%+ | ~150 lines |
| New York Variants | 0% | 70%+ | ~100 lines |

## 4-Week Remediation Plan

### Week 1: Component Implementation Tests (Target: 85% coverage)

#### Day 1-2: Button Component Enhancement
**Current**: 30.6% coverage (26/85 lines)
**Target**: 85% coverage (72/85 lines)

```rust
// Priority test areas:
1. All button variants (default, destructive, outline, secondary, ghost, link)
2. All button sizes (sm, default, lg, icon)
3. Loading states and disabled states
4. Event handling (click, focus, blur)
5. Accessibility features (ARIA attributes, keyboard navigation)
6. Theme integration and dynamic styling
7. Error boundary testing
8. Edge cases (empty children, invalid props)
```

**Implementation Tasks**:
- [x] Create comprehensive variant tests for all button types
- [x] Add size and state combination tests
- [x] Implement accessibility testing suite
- [x] Add event handling validation tests
- [x] Create theme integration tests
- [x] Add error boundary and edge case tests

**Status**: ✅ **COMPLETED** - Added 31 comprehensive implementation tests covering all button variants, sizes, event handling, accessibility, and edge cases.

#### Day 3-4: Input Component Enhancement
**Current**: 23.7% coverage (62/262 lines)
**Target**: 85% coverage (223/262 lines)

```rust
// Priority test areas:
1. All input types (text, email, password, number, tel, url)
2. Validation states (valid, invalid, pending)
3. Form integration and submission
4. Accessibility features (labels, descriptions, error messages)
5. Keyboard navigation and focus management
6. Real-time validation and debouncing
7. Custom validation rules
8. Integration with form libraries
```

**Implementation Tasks**:
- [x] Create input type-specific test suites
- [x] Add comprehensive validation testing
- [x] Implement form integration tests
- [x] Add accessibility compliance tests
- [x] Create keyboard navigation tests
- [x] Add real-time validation tests

**Status**: ✅ **COMPLETED** - Added 44 comprehensive implementation tests covering validation system, input types, accessibility, form integration, and edge cases.

## Signal Management Test Fixes - Session 5 Update

### Progress Summary
**Date**: Current Session  
**Focus**: Signal Management Test Error Resolution  
**Approach**: Targeted Manual Fixes

### Error Reduction Progress
- **Initial State**: 500 test errors
- **Current State**: 271 test errors  
- **Total Fixed**: 229 errors (46% reduction)
- **Remaining**: 271 errors

### Key Fixes Applied

#### 1. Queue Update API Alignment
**Issue**: Tests were using incorrect `queue_update` API calls
**Solution**: Converted from `queue_update(signal, value)` to proper closure-based calls
**Files Fixed**:
- `packages/signal-management/src/simple_tests/batched_updates_tests.rs`
- `packages/signal-management/src/signal_management_tests/batched_updates_tests.rs`
- `packages/signal-management/src/signal_management_tests/performance_tests.rs`

**Example Fix**:
```rust
// Before (incorrect)
updater.queue_update(signal.clone(), "update1".to_string());

// After (correct)
let signal_clone = signal.clone();
updater.queue_update(move || {
    signal_clone.set("update1".to_string());
}).unwrap();
```

#### 2. Missing Method Implementation
**Issue**: Tests calling non-existent `get_group()` method
**Solution**: Added missing method to `SignalMemoryManager`
**Implementation**:
```rust
/// Get a specific group by name
pub fn get_group(&self, group_name: &str) -> Option<SignalGroup> {
    self.tracked_groups.with(|groups| {
        groups.get(group_name).cloned()
    })
}
```

#### 3. Moved Value Issues
**Issue**: `cleanup.cleanup()` takes ownership, but tests try to use cleanup afterwards
**Solution**: Clone cleanup before calling cleanup method
**Pattern**:
```rust
// Before (causes moved value error)
cleanup.cleanup();
assert_eq!(cleanup.signals_count(), 0);

// After (fixed)
cleanup.clone().cleanup();
assert_eq!(cleanup.signals_count(), 0);
```

### Error Pattern Analysis
**Remaining Error Types**:
1. **Type Mismatches** (49 errors) - String literal type issues
2. **Moved Value Issues** (48 errors) - Ownership problems with cleanup
3. **Type Comparisons** (12 errors) - f64 vs integer comparisons
4. **Missing Methods** (13 errors) - API mismatches

### Strategy Refinements
1. **Targeted Manual Fixes**: Avoid broad batch operations that introduce new issues
2. **Systematic Approach**: Fix one error pattern at a time
3. **Validation**: Test progress after each set of fixes
4. **Revert When Needed**: Use git to revert problematic changes

### Next Steps
1. **Continue Moved Value Fixes**: Address remaining cleanup ownership issues
2. **Type Comparison Fixes**: Convert integer comparisons to float comparisons
3. **Missing Method Implementation**: Add remaining missing API methods
4. **Type Mismatch Resolution**: Fix string literal type issues

### Lessons Learned
1. **Batch Operations Risk**: sed commands can introduce syntax errors
2. **Manual Approach Works**: Targeted fixes are more reliable
3. **Progress Tracking**: Regular error count monitoring is essential
4. **Git Safety Net**: Reverting problematic changes maintains progress

#### Day 5-7: Card Component Enhancement
**Current**: 71.4% coverage (90/126 lines)
**Target**: 85% coverage (107/126 lines)

```rust
// Priority test areas:
1. All card variants (default, outlined, elevated)
2. Card composition (header, content, footer)
3. Interactive card states
4. Responsive behavior
5. Theme integration
6. Accessibility features
7. Performance optimization
```

**Implementation Tasks**:
- [ ] Add missing variant tests
- [ ] Create composition testing suite
- [ ] Implement interactive state tests
- [ ] Add responsive behavior tests
- [ ] Create theme integration tests

### Week 2: Signal Management Coverage (Target: 80% coverage)

#### Day 1-3: Core Signal Management
**Current**: 0% coverage (0/250 lines)
**Target**: 80% coverage (200/250 lines)

```rust
// Priority test areas:
1. Signal creation and initialization
2. Signal reading and writing
3. Signal derivation and computed values
4. Signal effects and side effects
5. Signal cleanup and memory management
6. Signal batching and optimization
7. Error handling in signal operations
8. Performance monitoring and profiling
```

**Implementation Tasks**:
- [ ] Create signal lifecycle tests
- [ ] Add signal derivation tests
- [ ] Implement effect testing suite
- [ ] Add memory management tests
- [ ] Create performance monitoring tests
- [ ] Add error handling tests

#### Day 4-5: Advanced Signal Features
```rust
// Advanced features to test:
1. Signal composition and chaining
2. Signal persistence and serialization
3. Signal debugging and introspection
4. Signal middleware and interceptors
5. Signal validation and type safety
6. Signal synchronization across components
```

#### Day 6-7: Signal Integration Tests
```rust
// Integration scenarios:
1. Multi-component signal sharing
2. Signal-based state management
3. Signal performance under load
4. Signal error recovery
5. Signal cleanup in component unmounting
```

### Week 3: Infrastructure Utilities (Target: 75% coverage)

#### Day 1-2: Test Utilities
**Current**: 0% coverage (0/253 lines)
**Target**: 75% coverage (190/253 lines)

```rust
// Priority test areas:
1. Component testing utilities
2. Mock and stub creation
3. Test data generation
4. Assertion helpers
5. Performance testing utilities
6. Accessibility testing helpers
7. Snapshot testing utilities
8. Property-based testing infrastructure
```

#### Day 3-4: Validation Utilities
```rust
// Validation testing:
1. Input validation logic
2. Form validation rules
3. Custom validator creation
4. Validation error handling
5. Validation performance
6. Validation accessibility
```

#### Day 5-7: Performance and Quality Utilities
```rust
// Performance testing:
1. Bundle size monitoring
2. Render performance testing
3. Memory usage monitoring
4. Accessibility compliance testing
5. Cross-browser compatibility testing
6. Performance regression detection
```

### Week 4: New York Variants & Polish (Target: 70% coverage)

#### Day 1-3: New York Variants
**Current**: 0% coverage (0/54 lines each)
**Target**: 70% coverage (38/54 lines each)

```rust
// New York variant testing:
1. Button New York variant
2. Card New York variant
3. Input New York variant
4. Variant-specific styling
5. Variant accessibility features
6. Variant performance characteristics
```

#### Day 4-5: Integration and E2E Tests
```rust
// End-to-end testing:
1. Complete user workflows
2. Cross-component interactions
3. Form submission flows
4. Navigation and routing
5. Error handling scenarios
6. Performance under realistic load
```

#### Day 6-7: Documentation and Examples
```rust
// Documentation and examples:
1. Create comprehensive examples (like Motion.dev)
2. Add interactive demos
3. Create tutorial content
4. Add performance benchmarks
5. Create accessibility guides
6. Add troubleshooting guides
```

## Implementation Strategy

### 1. Test-Driven Development Approach

```rust
// Example test structure for each component:
#[cfg(test)]
mod tests {
    use super::*;
    use leptos::*;
    use wasm_bindgen_test::*;
    
    // Basic functionality tests
    #[test]
    fn test_component_renders() {
        // Test basic rendering
    }
    
    // Variant tests
    #[test]
    fn test_all_variants() {
        // Test all component variants
    }
    
    // Accessibility tests
    #[test]
    fn test_accessibility_compliance() {
        // Test ARIA attributes, keyboard navigation
    }
    
    // Integration tests
    #[test]
    fn test_form_integration() {
        // Test form integration scenarios
    }
    
    // Performance tests
    #[test]
    fn test_performance_characteristics() {
        // Test render performance, memory usage
    }
    
    // Error handling tests
    #[test]
    fn test_error_scenarios() {
        // Test error boundaries, invalid props
    }
}
```

### 2. Coverage Monitoring

```bash
# Daily coverage checks
cargo llvm-cov --html --output-dir coverage/daily

# Weekly comprehensive analysis
cargo llvm-cov --html --output-dir coverage/weekly --workspace

# Coverage trend tracking
cargo llvm-cov --lcov --output-path coverage.lcov
```

### 3. Quality Gates

```yaml
# Coverage thresholds
component_implementation: 85%
signal_management: 80%
infrastructure_utilities: 75%
new_york_variants: 70%
overall_coverage: 90%
```

## Example Creation Strategy

### Motion.dev-Inspired Examples

Based on the [Motion for React examples](https://examples.motion.dev/react), we should create:

1. **Interactive Component Showcase**
   - Live component playground
   - Real-time prop editing
   - Theme switching demo
   - Accessibility testing tools

2. **Form Builder Example**
   - Dynamic form creation
   - Real-time validation
   - Form state management
   - Submission handling

3. **Dashboard Example**
   - Data visualization components
   - Interactive charts
   - Real-time updates
   - Responsive design

4. **Animation Examples**
   - Smooth transitions
   - Loading states
   - Micro-interactions
   - Performance optimization

## Success Metrics

### Week 1 Targets
- [ ] Button component: 85% coverage
- [ ] Input component: 85% coverage
- [ ] Card component: 85% coverage
- [ ] Overall component coverage: 80%+

### Week 2 Targets
- [ ] Signal management: 80% coverage
- [ ] Signal integration tests: 100% passing
- [ ] Performance benchmarks: Established

### Week 3 Targets
- [ ] Test utilities: 75% coverage
- [ ] Validation utilities: 75% coverage
- [ ] Performance utilities: 75% coverage

### Week 4 Targets
- [ ] New York variants: 70% coverage
- [ ] E2E test suite: Complete
- [ ] Example applications: 5+ created
- [ ] Overall coverage: 90%+

## Risk Mitigation

### Technical Risks
1. **Compilation Issues**: Maintain clean builds with daily checks
2. **Performance Regression**: Monitor bundle size and render times
3. **Test Flakiness**: Implement robust test infrastructure

### Timeline Risks
1. **Scope Creep**: Focus on coverage targets, not feature additions
2. **Quality vs Speed**: Maintain test quality standards
3. **Resource Constraints**: Prioritize high-impact areas first

## Conclusion

This 4-week plan provides a structured approach to achieving 90%+ test coverage while creating production-ready examples that rival the quality of [Motion.dev's React examples](https://examples.motion.dev/react). The focus on component implementation, signal management, and infrastructure utilities will significantly improve our code quality and maintainability.

**Key Success Factors**:
1. **Daily progress tracking** with coverage metrics
2. **Quality-first approach** with comprehensive test suites
3. **Example-driven development** with interactive demos
4. **Performance monitoring** throughout the process

**Expected Outcome**: A robust, well-tested component library with 90%+ coverage and production-ready examples that demonstrate the full capabilities of Leptos + ShadCN UI + tailwind-rs-core integration.