Back to Cookbook
Test Suite Speed Clinic
Make tests fast enough that devs actually run them
Reduce test runtime by separating unit/integration/e2e, improving isolation, enabling parallelism, and running the right tests at the right time.
CommunitySubmitted by CommunityWork15 min
INGREDIENTS
🐙GitHub
PROMPT
Create a skill called "Test Suite Speed Clinic". Inputs: - Current test types and runtimes (rough is OK) - CI constraints (parallel jobs, runner limits) Output: - A lane strategy (PR vs nightly vs on-demand) - A prioritized list of speedups (parallelism, isolation, fixtures) - A measurement plan (dashboards, budgets, regression detection)
How It Works
Slow tests create slow feedback loops. This recipe breaks the suite into lanes and
introduces optimization tactics that preserve coverage without blocking PRs for an hour.
Triggers
- PR pipeline spends most time running tests
- Developers avoid running tests locally due to slowness
- CI parallelism exists but isn't used effectively
Steps
- Measure and rank tests by runtime and flakiness.
- Split into lanes:
- PR gate: fast unit + critical integration,
- nightly: heavy integration/e2e/perf,
- on-demand: full matrix.
- Enable parallel execution for true unit tests.
- Reduce integration test setup costs (fixtures, shared containers, seeded DB snapshots).
- Add selective test execution where safe (changed-files mapping).
Expected Outcome
- PR checks become meaningfully faster.
- Teams regain the habit of running tests before pushing.
Example Inputs
- "800 tests, 45 minutes, developers rerun until green."
- "CI is 12 minutes but local is 1.5 minutes."
- "We need under 10-minute PR gates."
Tips
- The fastest test is the one you don't run—when it's safe not to.
Tags:#testing#ci-cd#performance#developer-productivity