leptos-shadcn-ui/docs/architecture/coverage-remediation-plan-v2.md

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)

// 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:

• Create comprehensive variant tests for all button types
• Add size and state combination tests
• Implement accessibility testing suite
• Add event handling validation tests
• Create theme integration tests
• 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)

// 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:

• Create input type-specific test suites
• Add comprehensive validation testing
• Implement form integration tests
• Add accessibility compliance tests
• Create keyboard navigation tests
• 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:

// 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:

/// 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:

// 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)

// 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)

// 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

// 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

// 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)

// 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

// 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

// 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)

// 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

// 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

// 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

// 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

# 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

# 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, 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. 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.