Skip to content

Test Coverage Analysis Prompt for Ruby Applications

Back to main README

Use the cov-loupe MCP server tool to analyze the test coverage data generated by simplecov for this Ruby project.

Generate a detailed coverage analysis report and output it to a markdown file named test_coverage_analysis.md.

The report should include:

1. Executive Summary

  • Overall coverage percentage and trend direction
  • High-level assessment of testing health across the application
  • Key strengths and critical gaps at a glance

2. Coverage by Application Component

Detailed analysis of coverage across different application layers: - Core Domain Logic: Business logic classes, domain models, and entities - Services/Commands: Service objects, command patterns, and use cases - Data Access Layer: Repository patterns, data mappers, database interactions - External Integrations: API clients, third-party service wrappers - Utilities/Helpers: Helper modules, utility classes, and shared functions - CLI Components: Command-line interface handlers and argument parsers (if applicable) - Configuration: Configuration classes and initialization logic - Lib files: Custom libraries and reusable modules - Concerns/Mixins: Shared modules and concerns

3. Well-Tested Areas

  • What's working well and why
  • Testing patterns and practices to replicate
  • Examples of strong test coverage with specific file references

4. Poorly-Tested Areas

Organize by: - Complexity to Test: Simple/Moderate/Complex (considering dependencies, I/O operations, external services, etc.) - Risk Level: High/Medium/Low (impact on data integrity, system reliability, business logic correctness) - Coverage Gap Size: Percentage of uncovered lines and number of untested methods

5. Priority Issues Table

Create a markdown table with these columns: - File/Module Path - Component Type (Service/Domain/Integration/etc.) - Current Coverage % - Uncovered Lines Count - Risk Level (High/Medium/Low) - Complexity to Fix (High/Medium/Low) - Priority Score (1-10, with 10 being highest priority) - Recommended Action (specific next steps)

Sort by Priority Score descending.

6. Ruby Application Testing Analysis

  • Domain Logic Testing: Coverage of business rules, validations, calculations, state transitions
  • Service Layer Testing: Coverage of orchestration logic, error handling, transaction boundaries
  • Data Access Testing: Coverage of queries, data transformations, persistence operations
  • Integration Testing: Testing of interactions between components and external systems
  • API Client Testing: Coverage of HTTP requests, response parsing, error handling
  • File I/O Operations: Testing of file reading/writing, parsing, serialization
  • Concurrency/Threading: Coverage of thread-safe operations, race conditions (if applicable)
  • Error Handling: Testing of exception handling, retry logic, fallback mechanisms
  • Security: Testing of input validation, data sanitization, authentication/authorization
  • Missing Test Types: Identify gaps in unit/integration/end-to-end tests

7. Common Ruby Testing Anti-Patterns Detected

  • Over-mocking leading to brittle tests
  • Missing edge case coverage in core domain logic
  • Untested error handling and failure scenarios
  • Missing tests for external service integrations
  • Lack of integration tests for critical workflows
  • Untested concurrency or threading logic (if applicable)
  • Insufficient testing of data transformation pipelines
  • Missing tests for CLI argument parsing and validation

8. Actionable Testing Roadmap

Prioritized list of specific issues to resolve, organized by effort level: - Quick Wins (< 2 hours): Simple tests with high impact - Sprint 1 (2-8 hours): Medium complexity, high priority - Sprint 2 (1-2 days): Complex but critical coverage gaps - Long-term (> 2 days): Large refactoring or architectural test improvements

Include specific file paths, method names, and recommended testing approaches for each item.

9. Metrics Dashboard

Key numbers: - Overall coverage percentage - Number of files at 0% coverage - Number of files at 100% coverage - Number of files above 90% coverage - Number of files below 50% coverage - Coverage by component type (Domain %, Services %, Integrations %, etc.) - Trend direction (if historical data available) - Lines of code vs lines of test code ratio - Average cyclomatic complexity of untested methods (if available)

10. Risk Assessment

  • Critical Paths: Identify core business workflows and their test coverage
  • High-Risk Untested Code: Data processing, financial calculations, authentication, data deletion, etc.
  • Security Implications: Areas where lack of tests could lead to vulnerabilities
  • Technical Debt: Old code with no tests that should be prioritized for coverage
  • External Dependencies: Integration points with poor test coverage
  • Data Integrity Risks: Operations that modify or delete data without adequate test coverage

Include specific file paths, line numbers, and code examples where relevant. Focus on actionable insights rather than just reporting numbers. Provide concrete recommendations for improving the test suite architecture and coverage strategy.