TESTER AGENTIC LOOP COMMAND - Comprehensive Test Generation System

Core Mission

Deploy a sophisticated multi-agent testing framework that analyzes code implementations and coordinates parallel test generation to achieve complete coverage without using mocks, while documenting any code issues discovered during the testing process.

Variables

source_directory: $ARGUMENTS
exclude_patterns: $ARGUMENTS (default: "node_modules,vendor,.git,dist,build,coverage")
test_output_strategy: $ARGUMENTS (default: "auto")
coverage_target: $ARGUMENTS (default: 100)
agent_count: $ARGUMENTS (default: 3, max: 10)
test_strategy: $ARGUMENTS (default: "comprehensive")
file_limit: $ARGUMENTS (default: 50)

ARGUMENTS PARSING

Parse the following arguments from "$ARGUMENTS":

source_directory - Root directory to recursively search for source files
exclude_patterns - Comma-separated patterns of directories/files to exclude
test_output_strategy - Test file placement: "auto", "same-dir", "test-dir", or custom path
coverage_target - Target test coverage percentage (1-100)
agent_count - Number of parallel testing agents to deploy
test_strategy - Testing approach: "comprehensive", "edge-cases", "integration", "performance"
file_limit - Maximum number of source files to process (safety limit)

PHASE 1: SOURCE DISCOVERY & ANALYSIS

Recursive Source File Discovery

Scan the source directory to find all testable source files:

FILE_DISCOVERY_PROCESS:
1. Start from source_directory root
2. Recursively traverse all subdirectories
3. Apply exclusion patterns to skip:
   - Version control directories (.git, .svn)
   - Dependencies (node_modules, vendor, packages)
   - Build outputs (dist, build, out, target)
   - Test directories (avoid testing tests)
   - Coverage reports
   - Hidden directories (unless explicitly included)
4. Identify source files by extension:
   - Go: *.go (exclude *_test.go)
   - Python: *.py (exclude test_*.py, *_test.py)
   - JavaScript/TypeScript: *.js, *.jsx, *.ts, *.tsx (exclude *.test.*, *.spec.*)
   - Java: *.java (exclude *Test.java, *Tests.java)
   - Rust: *.rs (exclude tests module)
   - C/C++: *.c, *.cpp, *.h, *.hpp
   - Ruby: *.rb (exclude *_spec.rb, *_test.rb)
5. Build source file inventory with metadata:
   - Full path
   - Relative path from source_directory
   - File size
   - Detected language
   - Module/package membership
   - Estimated complexity

Source File Prioritization

Rank discovered files for testing priority:

PRIORITIZATION_CRITERIA:
1. Core Business Logic (highest priority)
   - Files with names like: service, handler, controller, model
   - Files in directories: core, business, domain, logic
   - Files with high cyclomatic complexity
   
2. Public APIs and Interfaces
   - Files exposing external interfaces
   - REST/GraphQL endpoints
   - Library entry points
   
3. Data Processing and Algorithms
   - Files with computational logic
   - Data transformation modules
   - Algorithm implementations
   
4. Utilities and Helpers (lower priority)
   - Generic utility functions
   - Simple helper modules
   - Configuration files

BATCH_PROCESSING:
IF file_count > file_limit:
   - Sort by priority score
   - Process top 'file_limit' files
   - Document skipped files in report
   - Suggest running additional batches

Language Detection & Test Convention Analysis

Detect the implementation language and apply appropriate testing conventions:

LANGUAGE_TEST_CONVENTIONS:
Go:
  - Tests alongside source: file.go → file_test.go
  - Test package: same as source or source_test
  - Test function naming: TestFunctionName(t *testing.T)
  - Benchmark functions: BenchmarkFunctionName(b *testing.B)
  - Example functions: ExampleFunctionName()

Python:
  - Test directory: tests/ or test/
  - Test files: test_*.py or *_test.py
  - Test class/function naming: TestClass, test_function
  - Fixtures in conftest.py

JavaScript/TypeScript:
  - Test directory: __tests__/ or tests/
  - Test files: *.test.js, *.spec.js
  - Or alongside source: file.js → file.test.js
  - Jest/Mocha/Vitest conventions

Java:
  - Maven: src/test/java mirrors src/main/java
  - Gradle: similar structure
  - Test files: *Test.java or *Tests.java
  - JUnit annotations

Rust:
  - Unit tests: in same file with #[cfg(test)]
  - Integration tests: tests/ directory
  - Test functions: #[test] fn test_name()

C/C++:
  - Test directory: test/ or tests/
  - Test files: test_*.c or *_test.cpp
  - Framework specific (gtest, catch2, etc.)

Ruby:
  - RSpec: spec/ directory, *_spec.rb files
  - Minitest: test/ directory, *_test.rb files

Test Output Path Resolution

Determine appropriate test file locations:

PATH_RESOLUTION_LOGIC:
IF test_output_strategy == "auto":
    - Detect language from file extension
    - Apply language-specific conventions
    - For Go: place tests next to source files
    - For others: follow project structure or conventions
    
ELIF test_output_strategy == "same-dir":
    - Always place tests alongside source files
    - Use language-appropriate naming
    
ELIF test_output_strategy == "test-dir":
    - Create dedicated test directory structure
    - Mirror source directory hierarchy
    
ELSE:
    - Use custom path provided
    - Maintain language naming conventions

Deep Code Analysis

Perform comprehensive analysis on all discovered source files:

ANALYSIS_TASKS:
1. Parse all discovered source files
2. Build dependency graph between files
3. Identify shared components and interfaces
4. Map code execution paths across files
5. Detect integration points between modules
6. Analyze data flow through the system
7. Identify system entry points and boundaries
8. Calculate complexity metrics per file
9. Group files by functional domains
10. Detect testing challenges (DB access, external APIs, etc.)

Multi-File Coverage Planning

Create a comprehensive test coverage plan across all files:

SYSTEM_COVERAGE_MAP:
- Module Coverage: Group related files for integrated testing
- Cross-File Dependencies: Map inter-file function calls
- Integration Points: Identify where files interact
- System Boundaries: External dependencies per file
- Shared State: Identify shared resources/globals
- Test Isolation Strategy: How to test files independently
- Coverage Goals: Per-file and system-wide targets

PHASE 2: TESTING STRATEGY FORMULATION

File Distribution Among Agents

Distribute discovered files intelligently across agents:

DISTRIBUTION_STRATEGY:
Based on file_count and agent_count:

IF file_count <= agent_count:
   - Each agent gets 1 file
   - Each agent spawns 4 parallel sub-agents for test types
   
ELIF file_count <= (agent_count * 3):
   - Distribute files evenly
   - Group related files together
   - Each agent spawns multiple sub-agents
   
ELSE:
   - Create file clusters by:
     * Module/package membership
     * Dependency relationships
     * Functional domains
   - Assign clusters to agents
   - Balance workload by complexity

PARALLEL_SUB_AGENT_CALCULATION:
- Each main agent handles N files
- Each file gets 4 parallel sub-agents (unit, integration, edge, perf)
- Total parallel processes = agent_count * files_per_agent * 4
- Monitor system# TESTER AGENTIC LOOP COMMAND - Comprehensive Test Generation System

## Core Mission
Deploy a sophisticated multi-agent testing framework that analyzes code implementations and coordinates parallel test generation to achieve complete coverage without using mocks, while documenting any code issues discovered during the testing process.

## Variables

source_directory: $ARGUMENTS exclude_patterns: $ARGUMENTS (default: "node_modules,vendor,.git,dist,build,coverage") test_output_strategy: $ARGUMENTS (default: "auto") coverage_target: $ARGUMENTS (default: 100) agent_count: $ARGUMENTS (default: 3, max: 10) test_strategy: $ARGUMENTS (default: "comprehensive") file_limit: $ARGUMENTS (default: 50)


## ARGUMENTS PARSING
Parse the following arguments from "$ARGUMENTS":
1. `source_directory` - Root directory to recursively search for source files
2. `exclude_patterns` - Comma-separated patterns of directories/files to exclude
3. `test_output_strategy` - Test file placement: "auto", "same-dir", "test-dir", or custom path
4. `coverage_target` - Target test coverage percentage (1-100)
5. `agent_count` - Number of parallel testing agents to deploy
6. `test_strategy` - Testing approach: "comprehensive", "edge-cases", "integration", "performance"
7. `file_limit` - Maximum number of source files to process (safety limit)

## PHASE 1: SOURCE DISCOVERY & ANALYSIS

### Recursive Source File Discovery
Scan the source directory to find all testable source files:

FILE_DISCOVERY_PROCESS:

Start from source_directory root
Recursively traverse all subdirectories
Apply exclusion patterns to skip:
- Version control directories (.git, .svn)
- Dependencies (node_modules, vendor, packages)
- Build outputs (dist, build, out, target)
- Test directories (avoid testing tests)
- Coverage reports
- Hidden directories (unless explicitly included)
Identify source files by extension:
- Go: *.go (exclude *_test.go)
- Python: .py (exclude test_.py, *_test.py)
- JavaScript/TypeScript: *.js, *.jsx, *.ts, *.tsx (exclude .test., .spec.)
- Java: *.java (exclude *Test.java, *Tests.java)
- Rust: *.rs (exclude tests module)
- C/C++: *.c, *.cpp, *.h, *.hpp
- Ruby: *.rb (exclude *_spec.rb, *_test.rb)
Build source file inventory with metadata:
- Full path
- Relative path from source_directory
- File size
- Detected language
- Module/package membership
- Estimated complexity


### Source File Prioritization
Rank discovered files for testing priority:

PRIORITIZATION_CRITERIA:

Core Business Logic (highest priority)
- Files with names like: service, handler, controller, model
- Files in directories: core, business, domain, logic
- Files with high cyclomatic complexity
Public APIs and Interfaces
- Files exposing external interfaces
- REST/GraphQL endpoints
- Library entry points
Data Processing and Algorithms
- Files with computational logic
- Data transformation modules
- Algorithm implementations
Utilities and Helpers (lower priority)
- Generic utility functions
- Simple helper modules
- Configuration files

BATCH_PROCESSING: IF file_count > file_limit:

Sort by priority score
Process top 'file_limit' files
Document skipped files in report
Suggest running additional batches


### Language Detection & Test Convention Analysis
Detect the implementation language and apply appropriate testing conventions:

LANGUAGE_TEST_CONVENTIONS: Go:

Tests alongside source: file.go → file_test.go
Test package: same as source or source_test
Test function naming: TestFunctionName(t *testing.T)
Benchmark functions: BenchmarkFunctionName(b *testing.B)
Example functions: ExampleFunctionName()

Python:

Test directory: tests/ or test/
Test files: test_*.py or *_test.py
Test class/function naming: TestClass, test_function
Fixtures in conftest.py

JavaScript/TypeScript:

Test directory: tests/ or tests/
Test files: *.test.js, *.spec.js
Or alongside source: file.js → file.test.js
Jest/Mocha/Vitest conventions

Java:

Maven: src/test/java mirrors src/main/java
Gradle: similar structure
Test files: *Test.java or *Tests.java
JUnit annotations

Rust:

Unit tests: in same file with #[cfg(test)]
Integration tests: tests/ directory
Test functions: #[test] fn test_name()

C/C++:

Test directory: test/ or tests/
Test files: test_*.c or *_test.cpp
Framework specific (gtest, catch2, etc.)

Ruby:

RSpec: spec/ directory, *_spec.rb files
Minitest: test/ directory, *_test.rb files


### Test Output Path Resolution
Determine appropriate test file locations:

PATH_RESOLUTION_LOGIC: IF test_output_strategy == "auto": - Detect language from file extension - Apply language-specific conventions - For Go: place tests next to source files - For others: follow project structure or conventions

ELIF test_output_strategy == "same-dir": - Always place tests alongside source files - Use language-appropriate naming

ELIF test_output_strategy == "test-dir": - Create dedicated test directory structure - Mirror source directory hierarchy

ELSE: - Use custom path provided - Maintain language naming conventions

ANALYSIS_TASKS:

Parse implementation file structure and dependencies
Identify all classes, functions, and methods
Map code execution paths and branching logic
Detect external dependencies and integration points
Analyze data flow and state management
Identify potential edge cases and error conditions
Document API contracts and expected behaviors
Calculate cyclomatic complexity for each function
Map inheritance hierarchies and interface implementations
Identify concurrency patterns and potential race conditions


### Coverage Planning
Create a comprehensive test coverage plan:

COVERAGE_MAP:

Function Coverage: List all functions requiring tests
Branch Coverage: Map all conditional branches
Path Coverage: Identify all possible execution paths
Edge Case Coverage: Document boundary conditions
Error Coverage: List all error scenarios
Integration Coverage: Map external dependencies
Concurrency Coverage: Identify parallel execution scenarios


## PHASE 2: TESTING STRATEGY FORMULATION

### File Distribution Among Agents
Distribute discovered files intelligently across agents:

DISTRIBUTION_STRATEGY: Based on file count and agent_count:

IF file_count <= agent_count:

Each agent gets 1 file
Remaining agents assist with complex files

ELIF file_count <= (agent_count * 3):

Distribute files evenly
Group related files together

ELSE:

Create file clusters by:
- Module/package membership
- Dependency relationships
- Functional domains
Assign clusters to agents
Balance workload by complexity

AGENT_WORKLOAD_BALANCING:

Calculate complexity score per file
Sum complexity for agent assignments
Rebalance if any agent has >150% average load
Keep tightly coupled files with same agent


### Test Type Distribution Strategy
Each file gets parallel test generation across all test types:

PARALLEL_TEST_TYPE_STRATEGY: For EVERY source file, simultaneously generate:

UNIT TESTS (SubAgent-Unit)
- Individual function testing
- Pure logic validation
- Isolated component behavior
- Mock-free unit isolation
INTEGRATION TESTS (SubAgent-Integration)
- Cross-component interactions
- Database/API integrations
- End-to-end workflows
- System boundary testing
EDGE CASE TESTS (SubAgent-Edge)
- Boundary value analysis
- Error condition handling
- Null/empty/invalid inputs
- Race conditions and concurrency
PERFORMANCE TESTS (SubAgent-Performance)
- Benchmark functions
- Load testing scenarios
- Memory usage profiling
- Scalability analysis

PARALLEL_EXECUTION_BENEFITS:

4x faster test generation per file
Specialized focus improves quality
No test type gets neglected
Natural separation of concerns


### Dynamic Agent Orchestration
Scale parallel execution based on codebase size:

ORCHESTRATION_TIERS:

SMALL CODEBASE (1-10 files):

3 main agents
4 sub-agents per file per agent
Total: up to 120 parallel tasks
Focus: Comprehensive coverage

MEDIUM CODEBASE (11-50 files):

5 main agents
4 sub-agents per file per agent
Total: up to 200 parallel tasks
Focus: Balanced coverage and speed

LARGE CODEBASE (50+ files):

10 main agents
4 sub-agents per file per agent
Total: up to 400 parallel tasks
Focus: Efficient parallel processing
May process in batches to manage resources

RESOURCE_MANAGEMENT:

Monitor token usage across all sub-agents
Implement backpressure if system overloaded
Queue management for large parallel batches
Progress tracking across all parallel tasks


## PHASE 3: PARALLEL AGENT COORDINATION

### Git Worktree Setup for Parallel Execution

WORKTREE_INITIALIZATION: Before deploying sub-agents, prepare isolated workspaces:

WORKTREE_STRUCTURE: Main Repository ├── .git (shared) └── test-worktrees/ ├── agent-1-unit/ ├── agent-1-integration/ ├── agent-1-edge/ ├── agent-1-performance/ ├── agent-2-unit/ └── ... (one per sub-agent)
WORKTREE_CREATION_PROCESS: For each sub-agent:
- Create unique worktree branch: test-[agent]-[file]-[type]-[timestamp]
- Initialize worktree: git worktree add ../test-worktrees/[agent-id] -b [branch]
- Each sub-agent works in complete isolation
- No file conflicts between parallel agents
WORKTREE_BENEFITS:
- Complete file isolation between agents
- Easy rollback: git worktree remove [path]
- No merge conflicts during parallel execution
- Clean history with atomic test additions
- Simple cleanup after review
WORKTREE_LIFECYCLE:
- Create: Before sub-agent starts
- Work: Sub-agent generates tests in isolation
- Review: Examine changes in worktree
- Merge: If approved, merge to main branch
- Cleanup: Remove worktree and branch


### Sub-Agent Deployment Protocol

PARALLEL_TEST_TYPE_DEPLOYMENT: For each source file, deploy multiple parallel sub-agents per test type:

WORKTREE_SETUP: For EACH sub-agent:

# Create unique branch name
branch_name="test-${file_base}-${test_type}-${timestamp}"

# Create worktree
git worktree add ../test-worktrees/${agent_id} -b ${branch_name}

# Sub-agent works in this isolated directory
cd ../test-worktrees/${agent_id}

IMPLEMENTATION_CONTEXT:
- Complete code analysis report
- Assigned source files
- Test type specialization
- Coverage targets by test type
- Worktree path for isolated work
PARALLEL_TEST_GENERATION: For EACH source file: Deploy 4+ parallel sub-agents simultaneously:

SubAgent-Unit: Generate unit tests in worktree-unit SubAgent-Integration: Generate integration tests in worktree-integration SubAgent-Edge: Generate edge case tests in worktree-edge SubAgent-Performance: Generate performance tests in worktree-performance

Each sub-agent works in their own worktree Complete isolation, no file conflicts
TESTING_DIRECTIVES:
- NO MOCKS: All tests must use real implementations
- Test isolation: Each test type in separate file
- Work in assigned worktree directory
- Commit changes in worktree before completion
- Naming convention:
  - file.go → file_test.go (unit)
  - file.go → file_integration_test.go
  - file.go → file_edge_test.go
  - file.go → file_bench_test.go (performance)
QUALITY_REQUIREMENTS:
- Each test type must be comprehensive
- No duplication between test types
- Clear separation of concerns
- Performance tests include benchmarks
- Clean commits in worktree branches


### Parallel Agent Task Template

TASK: Generate [TEST_TYPE] tests for [FILE_PATH] in isolated worktree

You are SubAgent-[TEST_TYPE] for file: [FILE_PATH] Your worktree: [WORKTREE_PATH]

WORKTREE_CONTEXT:

You have an isolated Git worktree at: [WORKTREE_PATH]
Branch name: test-[FILE_BASE]-[TEST_TYPE]-[TIMESTAMP]
Work independently without affecting other agents
Commit your changes before completing

PARALLEL_CONTEXT:

You are one of 4+ agents working on this file simultaneously
Your focus: ONLY [TEST_TYPE] tests
Other agents are handling: [OTHER_TEST_TYPES]
Each agent has their own worktree - no conflicts!
Do NOT generate tests outside your type

WORKTREE_WORKFLOW:

Navigate to your worktree: cd [WORKTREE_PATH]
Verify you're on correct branch: git branch
Generate your test files
Run tests to ensure they work
Commit with message: "Add [TEST_TYPE] tests for [FILE_PATH]"
Report completion with commit SHA

TEST_TYPE_SPECIFIC_REQUIREMENTS:

For UNIT tests:

Test individual functions in isolation
Focus on single responsibility
Test pure logic and calculations
Use minimal setup/teardown

For INTEGRATION tests:

Test interactions between components
Test with real databases/services
Verify data flow between modules
Test API contracts

For EDGE tests:

Test boundary conditions
Test error scenarios
Test with invalid/extreme inputs
Test concurrency issues

For PERFORMANCE tests:

Create benchmark tests
Test with large datasets
Measure memory usage
Identify bottlenecks

DELIVERABLE:

One test file for your specific test type
Following naming: [filename]_[test_type]_test.[ext]
Comprehensive coverage of your test domain
Committed to your worktree branch
Ready for review and merge


### Parallel Execution Management

MASSIVE_PARALLEL_COORDINATION: Total parallel agents = file_count * test_types * agent_count

Example for 10 files with 4 test types and 3 base agents:

10 files distributed among 3 base agents
Each base agent spawns 4 sub-agents per file
Total: 40 parallel test generation tasks

ORCHESTRATION_PATTERN: Main Orchestrator ├── Agent 1 (handles files 1-3) │ ├── File1-Unit-SubAgent │ ├── File1-Integration-SubAgent │ ├── File1-Edge-SubAgent │ ├── File1-Performance-SubAgent │ ├── File2-Unit-SubAgent │ ├── File2-Integration-SubAgent │ ├── File2-Edge-SubAgent │ ├── File2-Performance-SubAgent │ └── [continues for File3...] ├── Agent 2 (handles files 4-7) │ └── [4 sub-agents per file] └── Agent 3 (handles files 8-10) └── [4 sub-agents per file]

SYNCHRONIZATION_POINTS:

File-level sync: All test types for a file complete
Agent-level sync: All files for an agent complete
Global sync: All agents complete
Merge phase: Combine all test files


### Agent Task Template

TASK: Generate tests for [FILE_COUNT] files in [DOMAIN] achieving [COVERAGE]% coverage

You are Testing Agent [NUMBER] responsible for testing [FILE_COUNT] source files.

FILE_ASSIGNMENTS: [List of assigned source files with paths]

CONTEXT:

Source directory: [SOURCE_DIRECTORY]
Total files in project: [TOTAL_FILE_COUNT]
Your assigned files: [FILE_LIST]
Code analysis: [ANALYSIS_SUMMARY]
Coverage target: [PERCENTAGE]%
Language mix: [LANGUAGES_IN_FILES]
Test output strategy: [STRATEGY]

REQUIREMENTS:

Analyze all assigned source files thoroughly
Understand interactions between your assigned files
Generate tests WITHOUT using any mocks
Create shared test fixtures for related files
Ensure each test file follows language conventions
Place test files according to [TEST_OUTPUT_STRATEGY]
Achieve at least [COVERAGE]% coverage per file
Document any untestable code or issues
Coordinate shared test utilities with other agents

DELIVERABLES:

Test files for each assigned source file
Shared test utilities/fixtures if needed
Issue report for problems found
Coverage report for your assigned files


### Parallel Execution Management

MASSIVE_PARALLEL_COORDINATION: Total parallel agents = file_count * test_types * agent_count Each agent gets its own Git worktree for isolation

Example for 10 files with 4 test types and 3 base agents:

10 files distributed among 3 base agents
Each base agent spawns 4 sub-agents per file
Total: 40 parallel test generation tasks
Total: 40 Git worktrees for complete isolation

ORCHESTRATION_PATTERN: Main Orchestrator ├── Agent 1 (handles files 1-3) │ ├── File1-Unit-SubAgent → worktree: test-file1-unit-1234 │ ├── File1-Integration-SubAgent → worktree: test-file1-integration-1234 │ ├── File1-Edge-SubAgent → worktree: test-file1-edge-1234 │ ├── File1-Performance-SubAgent → worktree: test-file1-perf-1234 │ ├── File2-Unit-SubAgent → worktree: test-file2-unit-1234 │ ├── File2-Integration-SubAgent → worktree: test-file2-integration-1234 │ ├── File2-Edge-SubAgent → worktree: test-file2-edge-1234 │ ├── File2-Performance-SubAgent → worktree: test-file2-perf-1234 │ └── [continues for File3...] ├── Agent 2 (handles files 4-7) │ └── [4 sub-agents per file, each with worktree] └── Agent 3 (handles files 8-10) └── [4 sub-agents per file, each with worktree]

WORKTREE_MANAGEMENT:

Pre-execution: Create all worktrees
During execution: Agents work in isolation
Post-execution: Review changes in each worktree
Merge phase: Selectively merge approved branches
Cleanup: Remove worktrees and branches

SYNCHRONIZATION_POINTS:

Worktree creation complete
File-level sync: All test types for a file complete
Agent-level sync: All files for an agent complete
Review checkpoint: Examine all worktree changes
Selective merge: Choose which tests to keep
Global sync: All merges complete
Cleanup: Remove all worktrees

INTER_AGENT_COMMUNICATION:

Shared test fixture registry (read-only)
Common test data repository (copy to worktree)
Cross-file integration test coordination
Discovered anti-patterns bulletin
Coverage gap notifications
Test type specific channels:
- Unit test helpers channel
- Integration test setup channel
- Edge case scenarios channel
- Performance baseline channel


## PHASE 4: ISSUE DETECTION & DOCUMENTATION

### Issue Tracking System

ISSUE_CATEGORIES:

CRITICAL: Code that cannot be tested due to fundamental issues
HIGH: Logic errors or inconsistencies discovered during testing
MEDIUM: Code smells or potential improvements
LOW: Style or minor optimization suggestions

ISSUE_REPORT_FORMAT: { "file": "path/to/implementation.py", "line": 42, "severity": "HIGH", "category": "LOGIC_ERROR", "description": "Function returns None when expecting integer", "discovered_by": "Agent 2 - Edge Case Hunter", "test_that_revealed": "test_calculate_total_with_empty_list", "suggested_fix": "Add validation for empty input", "blocking_tests": ["test_1", "test_2"] }


### Issue Report Generation

Each agent contributes to a unified issue report:

issues_report.json ├── critical_issues[] ├── high_priority_issues[] ├── medium_priority_issues[] ├── low_priority_issues[] ├── untestable_code[] ├── coverage_gaps[] └── recommendations[]


## PHASE 5: COVERAGE OPTIMIZATION LOOP

### Parallel Coverage Gap Analysis

PARALLEL_GAP_FILLING: After initial parallel test generation:

Aggregate coverage from all test types
Identify gaps in:
- Unit test coverage
- Integration test coverage
- Edge case coverage
- Performance test coverage
Deploy specialized gap-filling sub-agents:
- SubAgent-Unit-Gaps: Fill unit test gaps
- SubAgent-Integration-Gaps: Fill integration gaps
- SubAgent-Edge-Gaps: Add missing edge cases
- SubAgent-Performance-Gaps: Add benchmarks
Parallel gap-filling execution:
- All gap agents work simultaneously
- Target specific uncovered code
- Maximize coverage efficiently

ITERATIVE_PARALLEL_IMPROVEMENT: WHILE current_coverage < coverage_target: 1. Run parallel coverage analysis 2. Identify gaps by test type 3. Deploy 4 parallel gap-filling agents 4. Each targets their test type gaps 5. Merge results 6. Update coverage metrics

IF stuck_below_target:
    - Document why code cannot be tested
    - Add to untestable_code report
    - Provide refactoring suggestions


### Test Type Coverage Targets

COVERAGE_TARGETS_BY_TYPE:

Unit Tests: 80% minimum
Integration Tests: 60% minimum
Edge Cases: Must cover all identified boundaries
Performance: All public APIs benchmarked

PARALLEL_COVERAGE_MONITORING:

Real-time coverage tracking per test type
Dashboard showing parallel progress
Identify which test types need more work
Automatic rebalancing of agent efforts


## PHASE 6: TEST SUITE FINALIZATION

### Worktree Review and Selective Merge

WORKTREE_REVIEW_PROCESS: After all parallel sub-agents complete in their worktrees:

List all worktree branches:

git worktree list
git branch --list 'test-*'

Review each worktree:
- Examine test quality
- Check coverage metrics
- Validate test execution
- Assess code quality

Selective merge strategy:

# For approved tests
git merge test-file1-unit-1234 --no-ff -m "Add unit tests for file1"

# For tests needing revision
# Keep worktree active for fixes

# For rejected tests
git worktree remove test-worktrees/agent-x
git branch -D test-file1-edge-1234

Conflict resolution:
- Worktrees prevent conflicts during generation
- Only handle conflicts during selective merge
- Maintain test quality standards

WORKTREE_CLEANUP:

After review and merge

for worktree in test-worktrees/*; do git worktree remove "$worktree" done

Clean up merged branches

git branch --merged | grep 'test-' | xargs git branch -d

Clean up unmerged branches (if rejected)

git branch | grep 'test-' | xargs git branch -D


### Parallel Test Merge & Validation

PARALLEL_TEST_MERGE: After reviewing worktrees and selectively merging:

Collect test files by type:
- All unit test files (from merged branches)
- All integration test files (from merged branches)
- All edge case test files (from merged branches)
- All performance test files (from merged branches)
Merge strategy by language:
- Go: Keep separate _test.go files by type
- Python: Organize in test type subdirectories
- JavaScript: Separate test files with type suffix
Parallel validation runs:
- Run unit tests in parallel
- Run integration tests in parallel
- Run edge tests in parallel
- Run performance tests separately
Cross-test-type validation:
- Ensure no duplicate test cases
- Verify consistent test data usage
- Check for conflicting test fixtures
- Validate naming conventions

FINAL_PARALLEL_VALIDATION: Deploy 4 validation agents simultaneously:

Validator-Unit: Validate all unit tests
Validator-Integration: Validate integration suite
Validator-Edge: Validate edge cases
Validator-Performance: Validate benchmarks

Each validator ensures:

No flaky tests in their domain
Proper isolation between tests
Reasonable execution times
Clear test documentation


### Output Organization

PARALLEL_TEST_OUTPUT_STRUCTURE: project/ ├── src/ # Main repository │ ├── core/ │ │ ├── auth.go │ │ ├── auth_test.go # Unit tests (after merge) │ │ ├── auth_integration_test.go # Integration tests (after merge) │ │ ├── auth_edge_test.go # Edge case tests (after merge) │ │ └── auth_bench_test.go # Performance tests (after merge) │ └── api/ │ ├── handler.js │ ├── handler.test.js # Unit tests (after merge) │ ├── handler.integration.test.js │ ├── handler.edge.test.js │ └── handler.perf.test.js ├── test-worktrees/ # Temporary during execution │ ├── agent-1-file1-unit/ # Worktree for unit tests │ ├── agent-1-file1-integration/ # Worktree for integration │ ├── agent-1-file1-edge/ # Worktree for edge cases │ ├── agent-1-file1-perf/ # Worktree for performance │ └── ... (40+ worktrees for large projects) ├── test-reports/ │ ├── parallel-execution-summary.md │ ├── worktree-review-log.md # Review decisions for each worktree │ ├── coverage/ │ │ ├── unit-coverage.html │ │ ├── integration-coverage.html │ │ ├── edge-coverage.html │ │ └── combined-coverage.html │ ├── performance/ │ │ ├── benchmarks.json │ │ └── performance-report.html │ └── timing/ │ ├── parallel-execution-time.json │ └── test-type-duration.csv └── issues/ ├── issues-by-test-type.json ├── worktree-branches.txt # List of all created branches └── parallel-execution-log.txt

WORKTREE_METRICS_REPORT: { "execution_summary": { "total_files_tested": 50, "total_parallel_agents": 200, "total_worktrees_created": 200, "execution_time": "12m 34s", "parallelization_speedup": "8.5x" }, "worktree_summary": { "branches_created": 200, "branches_merged": 180, "branches_rejected": 15, "branches_pending_review": 5 }, "test_generation": { "unit_tests": 500, "integration_tests": 200, "edge_tests": 300, "performance_tests": 100 }, "review_decisions": { "auto_merged": 150, "manually_reviewed": 30, "rejected_quality": 10, "rejected_duplicate": 5, "pending_fixes": 5 } }


## EXECUTION PRINCIPLES

### Git Worktree Isolation
- Every sub-agent works in a separate Git worktree
- Complete file isolation prevents conflicts
- Easy review of generated tests before merging
- Simple rollback by removing worktree
- Clean git history with atomic test additions

### Scalable Testing
- Handle single files to entire codebases efficiently
- Dynamically adjust agent strategies based on scale
- Process files in priority order when hitting limits
- Provide clear progress reporting for large jobs
- Worktrees scale linearly with agent count

### Quality Over Quantity
- Generate fewer, high-quality tests rather than many poor tests
- Each test should clearly document what it's testing
- Tests should serve as living documentation
- Respect file-specific patterns and idioms
- Review in worktrees before merging

### Real-World Testing
- No mocks means testing actual behavior
- Use test databases, test files, test servers
- Create realistic test data and scenarios
- Test the system as users would use it
- Each worktree has full environment access

### Collaborative Intelligence
- Agents share discoveries and test utilities
- Cross-file dependencies tested coherently
- Build comprehensive test suite together
- Learn from patterns across the codebase
- Worktree isolation with shared knowledge

### Continuous Improvement
- Each file's tests inform testing of related files
- Refactor shared test utilities for reuse
- Optimize test execution time across suite
- Enhance coverage strategically
- Easy A/B testing with worktree branches

## ULTRA-THINKING DIRECTIVE

Before beginning test generation, engage in deep analysis:

### Worktree Strategy
- How many worktrees can the system handle efficiently?
- What's the optimal branch naming convention?
- How to organize worktrees for easy review?
- When to auto-merge vs require manual review?

### Parallel Execution Strategy
- How to orchestrate 4 test types per file efficiently?
- What's the optimal parallelization for this codebase size?
- How to prevent resource exhaustion with many sub-agents?
- When to batch vs full parallel execution?

### Test Type Specialization
- What makes a good unit test vs integration test?
- How to ensure edge cases don't overlap with unit tests?
- What performance metrics matter for this codebase?
- How to maintain clear boundaries between test types?

### Codebase Comprehension
- What is the overall architecture of this system?
- How do the discovered files relate to each other?
- What are the critical paths through the codebase?
- Where are the likely failure points?

### Scale-Aware Parallel Testing
- How many parallel agents can we effectively run?
- What's the token usage for parallel test generation?
- How to coordinate shared test resources?
- When to synchronize vs continue in parallel?

### Agent Orchestration
- How to maximize parallel efficiency across test types?
- How to coordinate tests for tightly coupled files?
- How to share test utilities across parallel agents?
- How to handle sub-agent failures gracefully?

### Issue Detection Across Test Types
- What issues do unit tests reveal vs integration?
- How do edge cases expose different problems?
- What performance issues need highlighting?
- How to consolidate findings from all test types?

### Worktree Management
- How to efficiently create and destroy worktrees?
- What's the review process for each worktree?
- How to handle merge conflicts during consolidation?
- When to keep vs discard generated tests?

Begin execution with thorough directory scanning and analysis, then deploy your army of parallel specialized testing agents - 4 sub-agents per file (unit, integration, edge, performance) - each working in isolated Git worktrees to achieve comprehensive, real-world test coverage across the entire codebase while documenting every issue discovered along the way.

lanzafame/README.md