|
| 1 | +--- |
| 2 | +sidebar_position: 4 |
| 3 | +--- |
| 4 | + |
| 5 | +# Parallel Execution |
| 6 | + |
| 7 | +Doc Detective supports parallel execution of test contexts using a configurable worker pool pattern. This feature can significantly improve performance for test suites with multiple contexts by running them concurrently instead of sequentially. |
| 8 | + |
| 9 | +## How It Works |
| 10 | + |
| 11 | +By default, Doc Detective executes test contexts sequentially (one after another). With parallel execution enabled, Doc Detective creates multiple worker processes that can execute different test contexts simultaneously while maintaining proper test isolation. |
| 12 | + |
| 13 | +Each test context gets its own independent browser driver instance and execution environment, ensuring that tests don't interfere with each other even when running in parallel. |
| 14 | + |
| 15 | +## Configuration |
| 16 | + |
| 17 | +Enable parallel execution by setting the `concurrentRunners` field in your configuration: |
| 18 | + |
| 19 | +```json |
| 20 | +{ |
| 21 | + "input": "./tests", |
| 22 | + "concurrentRunners": 4 |
| 23 | +} |
| 24 | +``` |
| 25 | + |
| 26 | +### Configuration Options |
| 27 | + |
| 28 | +- **`concurrentRunners`**: Number of concurrent workers to use |
| 29 | + - Default: `1` (sequential execution) |
| 30 | + - Recommended: 2-4 workers for most systems |
| 31 | + - Maximum: Limited by your system's resources |
| 32 | + |
| 33 | +## Performance Benefits |
| 34 | + |
| 35 | +Parallel execution can provide significant performance improvements: |
| 36 | + |
| 37 | +- **2 workers**: Typically 1.5-1.7x speedup |
| 38 | +- **4 workers**: Typically 2-2.5x speedup |
| 39 | +- **Higher worker counts**: Diminishing returns due to system overhead |
| 40 | + |
| 41 | +The actual speedup depends on: |
| 42 | +- Number of test contexts in your test suite |
| 43 | +- System resources (CPU, memory) |
| 44 | +- Test complexity and duration |
| 45 | +- Browser startup overhead |
| 46 | + |
| 47 | +## Best Practices |
| 48 | + |
| 49 | +### Choosing Worker Count |
| 50 | + |
| 51 | +- **Start with 2-4 workers** for most systems |
| 52 | +- **Monitor system resources** when increasing worker count |
| 53 | +- **Consider test suite size**: More workers than contexts provides no benefit |
| 54 | +- **Test different configurations** to find optimal performance |
| 55 | + |
| 56 | +### Test Design Considerations |
| 57 | + |
| 58 | +- **Ensure test isolation**: Tests should not depend on shared state |
| 59 | +- **Avoid resource conflicts**: Tests shouldn't compete for the same files or ports |
| 60 | +- **Use unique identifiers**: Generate unique test data to prevent conflicts |
| 61 | + |
| 62 | +### System Requirements |
| 63 | + |
| 64 | +- **Memory**: Each worker requires additional memory for browser instances |
| 65 | +- **CPU**: Multiple workers benefit from multi-core processors |
| 66 | +- **Browser resources**: Each context gets its own browser driver |
| 67 | + |
| 68 | +## Examples |
| 69 | + |
| 70 | +### Basic Parallel Configuration |
| 71 | + |
| 72 | +```json |
| 73 | +{ |
| 74 | + "input": "./tests", |
| 75 | + "concurrentRunners": 2, |
| 76 | + "logLevel": "info" |
| 77 | +} |
| 78 | +``` |
| 79 | + |
| 80 | +### Advanced Configuration with Multiple Contexts |
| 81 | + |
| 82 | +```json |
| 83 | +{ |
| 84 | + "input": "./tests", |
| 85 | + "concurrentRunners": 4, |
| 86 | + "runOn": [ |
| 87 | + { |
| 88 | + "platform": "linux", |
| 89 | + "browser": "chrome" |
| 90 | + }, |
| 91 | + { |
| 92 | + "platform": "linux", |
| 93 | + "browser": "firefox" |
| 94 | + } |
| 95 | + ] |
| 96 | +} |
| 97 | +``` |
| 98 | + |
| 99 | +### Command Line Override |
| 100 | + |
| 101 | +You can override the configuration from the command line: |
| 102 | + |
| 103 | +```bash |
| 104 | +npx doc-detective --config .doc-detective.json --concurrentRunners 3 |
| 105 | +``` |
| 106 | + |
| 107 | +## Troubleshooting |
| 108 | + |
| 109 | +### Performance Issues |
| 110 | + |
| 111 | +- **Reduce worker count** if system becomes unresponsive |
| 112 | +- **Monitor memory usage** - each worker uses additional RAM |
| 113 | +- **Check for resource contention** between parallel tests |
| 114 | + |
| 115 | +### Test Failures |
| 116 | + |
| 117 | +- **Verify test isolation** - ensure tests don't share state |
| 118 | +- **Check for timing issues** - parallel execution may expose race conditions |
| 119 | +- **Review error logs** - failed contexts are reported with detailed error information |
| 120 | + |
| 121 | +### Browser Issues |
| 122 | + |
| 123 | +- **Ensure sufficient browser resources** for multiple instances |
| 124 | +- **Consider headless mode** to reduce resource usage |
| 125 | +- **Check browser driver compatibility** with parallel execution |
| 126 | + |
| 127 | +## Migration from Sequential Execution |
| 128 | + |
| 129 | +Existing test suites work unchanged with parallel execution: |
| 130 | + |
| 131 | +1. **No breaking changes** - all existing tests continue to work |
| 132 | +2. **Gradual adoption** - start with `concurrentRunners: 2` |
| 133 | +3. **Monitor results** - verify test outcomes remain consistent |
| 134 | +4. **Optimize incrementally** - increase worker count based on performance gains |
| 135 | + |
| 136 | +## Error Handling |
| 137 | + |
| 138 | +Parallel execution maintains robust error handling: |
| 139 | + |
| 140 | +- **Isolated failures**: Error in one context doesn't terminate others |
| 141 | +- **Complete results**: All test results are collected regardless of execution order |
| 142 | +- **Detailed reporting**: Failed contexts include full error details |
| 143 | +- **Graceful cleanup**: Resources are properly cleaned up even on failures |
0 commit comments