Implement Parallel Test Context Execution

[hawkeyexl]

Description

Implement parallel execution of resolved test contexts using a worker pool pattern, replacing the current sequential execution loop.

Requirements

Dependencies

• doc-detective-resolver v3.1.1-dev.3

Core Functionality

• Process resolved test contexts through configurable number of workers
• Maintain existing test isolation (Appium browsers, shell instances, etc.)
• Preserve error handling and result collection
• Support both sequential (1 worker) and parallel (N workers) execution

Implementation Approach

Implement a TestRunner class with worker pool pattern:

class TestRunner {
  constructor(concurrentRunners) {
    this.maxWorkers = concurrentRunners;
    this.contextQueue = [];
    this.results = [];
  }

  async runTests(resolvedContexts) {
    this.contextQueue = [...resolvedContexts];
    
    // Create worker promises
    const workers = Array.from({ length: this.maxWorkers }, () => 
      this.createWorker()
    );
    
    await Promise.allSettled(workers);
    return this.results;
  }

  async createWorker() {
    while (this.contextQueue.length > 0) {
      const context = this.contextQueue.shift();
      if (!context) break;
      
      try {
        const result = await this.executeTestContext(context);
        this.results.push(result);
      } catch (error) {
        this.results.push({ context, error, status: 'failed' });
      }
    }
  }
}

Integration Points

• Replace existing sequential test execution loop
• Receive concurrentRunners value from resolver
• Use existing executeTestContext function for individual test execution
• Maintain existing result format and error handling

Acceptance Criteria

• Sequential execution (concurrentRunners: 1) works identically to current behavior
• Parallel execution processes multiple contexts simultaneously
• Test isolation maintained - no cross-context interference
• All test results collected regardless of execution order
• Error in one context doesn't terminate others
• Failed contexts properly reported with error details
• Progress reporting works during parallel execution
• Memory usage scales predictably with worker count
• Performance improves for parallelizable test suites

Implementation Notes

• Reuse existing test execution logic - don't reimplement test running
• Ensure proper cleanup if execution is interrupted
• Consider using Promise.allSettled() to handle worker failures gracefully
• Maintain existing logging and progress reporting mechanisms
• Queue should be thread-safe for worker access patterns

Testing Strategy

• Unit tests for worker pool logic
• Integration tests with various concurrency levels (1, 2, 4, 8)
• Test isolation verification - multiple browser tests, shell commands
• Error handling tests - failures in some but not all contexts
• Performance benchmarking - measure actual speedup
• Resource usage monitoring - ensure no memory leaks

Performance Considerations

• Browser tests are most resource-intensive - test with realistic browser loads
• Shell/code execution should be lightweight and parallel-friendly
• Consider startup overhead vs. execution time for small test suites
• Monitor system resource usage during high-concurrency testing