Test Orchestrator
Overview
Coordinate parallel test execution across multiple test suites, frameworks, and environments. Manages test splitting, worker allocation, result aggregation, and intelligent retry strategies.
Prerequisites
- Test runner with parallel execution support (Jest, Vitest, pytest-xdist, Playwright, or JUnit 5)
- CI/CD platform configured (GitHub Actions, GitLab CI, CircleCI, or Jenkins)
- Test suite with consistent pass rates (flaky tests identified and tagged)
- Sufficient CI runner resources for parallel worker count
- Test result reporting tool (JUnit XML, Allure, or equivalent)
Instructions
- Analyze the existing test suite using Grep and Glob to catalog all test files, their framework, approximate run time, and dependency requirements.
- Classify tests into execution tiers:
- Tier 1 (Fast): Unit tests with no I/O -- target under 30 seconds total.
- Tier 2 (Medium): Integration tests requiring local services -- target under 3 minutes.
- Tier 3 (Slow): E2E and browser tests -- target under 10 minutes.
- Configure parallel execution for each tier:
- Split unit tests across N workers using
jest --shard=i/N or pytest -n auto.
- Shard E2E tests by test file using Playwright
--shard=i/N or Cypress parallelization.
- Assign heavier integration tests to dedicated workers with more resources.
- Create a CI pipeline configuration that runs tiers in parallel:
- Tier 1 and Tier 2 run concurrently on separate jobs.
- Tier 3 runs after a fast pre-check gate passes.
- Each tier reports results to a unified collection step.
- Implement intelligent retry logic for flaky tests:
- Tag known flaky tests with
@flaky or equivalent marker.
- Retry failed tests up to 2 times before marking as failed.
- Track flaky test frequency in a log file for triage.
- Aggregate results from all parallel workers into a single report:
- Merge JUnit XML files from each shard.
- Calculate total pass/fail/skip counts and execution time.
- Identify the slowest tests for optimization targets.
- Write the orchestration configuration to the project's CI config file and validate it with a dry run.
Output
- CI pipeline configuration file (
.github/workflows/test.yml, .gitlab-ci.yml, or equivalent)
- Test sharding configuration with worker count and split strategy
- Merged test result report in JUnit XML or JSON format
- Execution timeline showing parallel job durations and bottlenecks
- Flaky test inventory with retry counts and failure patterns
Error Handling
| Error |
Cause |
Solution |
| Shard produces zero tests |
Uneven test distribution or incorrect shard index |
Verify shard count matches actual test file count; use file-based splitting |
| Worker out of memory |
Too many parallel processes on one runner |
Reduce --maxWorkers or -n count; increase runner memory; use --workerIdleMemoryLimit |
| Test ordering dependency |
Tests pass in isolation but fail in specific shard order |
Add --randomize flag; fix shared state leaks; enforce test independence |
| Result aggregation mismatch |
Missing shard results due to job timeout |
Set job-level timeouts higher than test timeouts; add result upload as a separate step |
| CI cache miss slowing startup |
Dependencies not cached between parallel jobs |
Configure dependency caching per lockfile hash; use a shared setup job |
Examples
GitHub Actions matrix strategy for Jest sharding:
jobs:
test:
strategy:
matrix:
shard: [1, 2, 3, 4]
steps:
- run: npx jest --shard=${{ matrix.shard }}/4 --ci --reporters=jest-junit
- uses: actions/upload-artifact@v4
with:
name: results-${{ matrix.shard }}
path: junit.xml
merge:
needs: test
steps:
- uses: actions/download-artifact@v4
- run: npx junit-merge -d results-* -o merged-results.xml
pytest-xdist parallel execution:
pytest -n auto --dist worksteal -q --junitxml=results.xml
Playwright sharded execution:
npx playwright test --shard=1/3 --reporter=junit
Resources
Source: jeremylongshore/claude-code-plugins-plus-skills → skills/.curated/orchestrating-test-execution/SKILL.md
Also appears in: jeremylongshore/claude-code-plugins-plus-skills/plugins/testing/test-orchestrator/skills/orchestrating-test-execution/SKILL.md
1---2name: orchestrating-test-execution3description: "'Test coordinate parallel test execution across multiple environments and frameworks. Use when performing specialized testing. Trigger with phrases like \"orchestrate tests\", \"run parallel tests\", or \"coordinate test execution\". '"4allowed-tools: "Read, Write, Edit, Grep, Glob, Bash(test:orchestrate-*)"5category: testing-and-qa6source_repo: jeremylongshore/claude-code-plugins-plus-skills7source_path: "skills/.curated/orchestrating-test-execution/SKILL.md"8source_url: https://github.com/jeremylongshore/claude-code-plugins-plus-skills/blob/HEAD/skills/.curated/orchestrating-test-execution/SKILL.md9---1011# Test Orchestrator1213## Overview1415Coordinate parallel test execution across multiple test suites, frameworks, and environments. Manages test splitting, worker allocation, result aggregation, and intelligent retry strategies.1617## Prerequisites1819- Test runner with parallel execution support (Jest, Vitest, pytest-xdist, Playwright, or JUnit 5)20- CI/CD platform configured (GitHub Actions, GitLab CI, CircleCI, or Jenkins)21- Test suite with consistent pass rates (flaky tests identified and tagged)22- Sufficient CI runner resources for parallel worker count23- Test result reporting tool (JUnit XML, Allure, or equivalent)2425## Instructions26271. Analyze the existing test suite using Grep and Glob to catalog all test files, their framework, approximate run time, and dependency requirements.282. Classify tests into execution tiers:29 - **Tier 1 (Fast)**: Unit tests with no I/O -- target under 30 seconds total.30 - **Tier 2 (Medium)**: Integration tests requiring local services -- target under 3 minutes.31 - **Tier 3 (Slow)**: E2E and browser tests -- target under 10 minutes.323. Configure parallel execution for each tier:33 - Split unit tests across N workers using `jest --shard=i/N` or `pytest -n auto`.34 - Shard E2E tests by test file using Playwright `--shard=i/N` or Cypress parallelization.35 - Assign heavier integration tests to dedicated workers with more resources.364. Create a CI pipeline configuration that runs tiers in parallel:37 - Tier 1 and Tier 2 run concurrently on separate jobs.38 - Tier 3 runs after a fast pre-check gate passes.39 - Each tier reports results to a unified collection step.405. Implement intelligent retry logic for flaky tests:41 - Tag known flaky tests with `@flaky` or equivalent marker.42 - Retry failed tests up to 2 times before marking as failed.43 - Track flaky test frequency in a log file for triage.446. Aggregate results from all parallel workers into a single report:45 - Merge JUnit XML files from each shard.46 - Calculate total pass/fail/skip counts and execution time.47 - Identify the slowest tests for optimization targets.487. Write the orchestration configuration to the project's CI config file and validate it with a dry run.4950## Output5152- CI pipeline configuration file (`.github/workflows/test.yml`, `.gitlab-ci.yml`, or equivalent)53- Test sharding configuration with worker count and split strategy54- Merged test result report in JUnit XML or JSON format55- Execution timeline showing parallel job durations and bottlenecks56- Flaky test inventory with retry counts and failure patterns5758## Error Handling5960| Error | Cause | Solution |61|-------|-------|---------|62| Shard produces zero tests | Uneven test distribution or incorrect shard index | Verify shard count matches actual test file count; use file-based splitting |63| Worker out of memory | Too many parallel processes on one runner | Reduce `--maxWorkers` or `-n` count; increase runner memory; use `--workerIdleMemoryLimit` |64| Test ordering dependency | Tests pass in isolation but fail in specific shard order | Add `--randomize` flag; fix shared state leaks; enforce test independence |65| Result aggregation mismatch | Missing shard results due to job timeout | Set job-level timeouts higher than test timeouts; add result upload as a separate step |66| CI cache miss slowing startup | Dependencies not cached between parallel jobs | Configure dependency caching per lockfile hash; use a shared setup job |6768## Examples6970**GitHub Actions matrix strategy for Jest sharding:**7172```yaml73jobs:74 test:75 strategy:76 matrix:77 shard: [1, 2, 3, 4]78 steps:79 - run: npx jest --shard=${{ matrix.shard }}/4 --ci --reporters=jest-junit80 - uses: actions/upload-artifact@v481 with:82 name: results-${{ matrix.shard }}83 path: junit.xml84 merge:85 needs: test86 steps:87 - uses: actions/download-artifact@v488 - run: npx junit-merge -d results-* -o merged-results.xml89```9091**pytest-xdist parallel execution:**9293```bash94pytest -n auto --dist worksteal -q --junitxml=results.xml95```9697**Playwright sharded execution:**9899```bash100npx playwright test --shard=1/3 --reporter=junit101```102103## Resources104105- Jest sharding: https://jestjs.io/docs/cli#--shardshardindex-shardcount106- pytest-xdist: https://pytest-xdist.readthedocs.io/107- Playwright test sharding: https://playwright.dev/docs/test-sharding108- GitHub Actions matrix strategy: https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs109- JUnit XML merge tools:110111---112113**Source:** [`jeremylongshore/claude-code-plugins-plus-skills`](https://github.com/jeremylongshore/claude-code-plugins-plus-skills) → `skills/.curated/orchestrating-test-execution/SKILL.md`114115**Also appears in:** `jeremylongshore/claude-code-plugins-plus-skills/plugins/testing/test-orchestrator/skills/orchestrating-test-execution/SKILL.md`