blind-spot-coverage

name

blind-spot-coverage

description

Use this skill when the user wants to add test coverage targeting blind spots in a specific method — uncovered branches, edge cases, or unusual inputs. Activate on explicit requests to cover blind spots or when the user asks "what should I test here?" about a particular method. This is not about achieving 100% line coverage, but about ensuring the method behaves correctly in scenarios that are easy to miss.

Blind Spot Coverage

Activate when the user wants to identify and cover blind spots in a specific method's test coverage. The goal is to find what the existing tests don't cover — the edge cases, error paths, and unusual inputs that could break the method.

Input

The user provides:

• Target method (required): The specific method/function to analyze (e.g., UserService.validateEmail, parseConfig)
• Context (optional): Any specific concerns or areas they want to focus on

Example: /blind-spot-coverage UserService.validateEmail

Procedure

1. Locate the method

Find the method in the codebase. Read it thoroughly, including:

• The method signature and return type
• All parameters and their types
• The full implementation body
• Any helper methods it calls internally

2. Find existing tests

Locate all existing tests for this method. Look for:

• Test files with matching names (e.g., UserService.test.ts, test_user_service.py)
• Test cases that explicitly call this method
• Integration tests that exercise it indirectly

Read all existing test cases to understand what's already covered.

3. Analyze the method for blind spots

For the target method, identify categories of blind spots:

A. Input edge cases

• Empty strings, null, undefined, zero, negative numbers
• Minimum and maximum valid values (boundary conditions)
• Values just outside valid ranges
• Special characters or unusual formats
• Extremely long inputs (performance/overflow concerns)

B. State edge cases

• Empty collections, initialized but unused state
• Concurrent access or race conditions (if applicable)
• State transitions that skip expected steps

C. Error paths

• Exceptions that could be thrown but aren't tested
• Error conditions that return special values (null, error objects)
• Network timeouts or external service failures (for I/O methods)
• Permission/authorization failures

D. Logic branches

• Every if/else branch
• Every switch/case path including default
• Every loop (empty iteration, single item, multiple items)
• Early returns and exit conditions

E. External dependencies

• API calls that could fail
• Database queries that return no results
• File system operations (file not found, permission denied)
• Third-party library edge cases

F. Time-sensitive operations

• Operations that depend on current time/date
• Timeout conditions
• Retry logic

4. Cross-reference with existing tests

For each blind spot category, check if existing tests already cover it. Mark as:

• ❌ Uncovered: No test exists for this scenario
• ⚠️ Partially covered: Some but not all aspects tested
• ✅ Covered: Adequately tested

5. Prioritize blind spots

Not all blind spots are equally important. Prioritize by:

High priority (cover these first):

• Error paths that could cause crashes
• Input validation failures
• Security-sensitive operations
• Data corruption risks

Medium priority:

• Boundary conditions
• Edge cases in business logic
• External dependency failures

Low priority:

• Unusual but harmless inputs
• Performance edge cases (unless explicitly requested)
• Cosmetic issues

6. Generate test suggestions

For each high and medium priority uncovered blind spot, provide:

1. The scenario in plain English
2. Why it matters in one sentence
3. Test code template showing how to test it

Format:

## Blind Spots Found

### [MethodName]

#### ❌ [Scenario description]
> **Why:** [one-sentence rationale]

**Test:**
```[language]
[test code template]

Group similar scenarios together. Include the file path and line numbers for reference.

### 7. Deliver the analysis

Present findings in this order:
1. Brief summary of what the method does
2. Existing test coverage overview
3. Prioritized list of blind spots
4. Test code templates for each

End with a question: "Which of these would you like me to implement as actual tests?"

## Guidelines

- **Be pragmatic**: Focus on value, not completeness. A method might have 50 theoretical edge cases but only 5 worth testing.
- **Respect existing style**: Match the test style, framework, and patterns already used in the codebase.
- **Stay focused**: One method at a time. Don't expand scope to the entire class or module unless explicitly asked.
- **No false positives**: Only report blind spots that actually exist. Verify the code path is real.
- **Language-aware**: Adapt to the language's testing conventions (Jest, pytest, RSpec, etc.)