feat: parallel test case execution #261

New issue

Closed

opened 2026-02-27 00:21:07 +00:00 by barrettruth · 0 comments

barrettruth commented

2026-02-27 00:21:07 +00:00

Problem

run_all_test_cases in lua/cp/runner/run.lua runs test cases sequentially via a recursive run_next callback. For problems with many test cases (e.g., 10+ after editing), this is significantly slower than necessary. Test cases are fully independent and there is no reason to serialize them.

Proposed solution

Run all test cases concurrently using a counter-based completion barrier:

local pending = #to_run
for i, idx in ipairs(to_run) do
  M.run_test_case(idx, debug, function()
    pending = pending - 1
    if on_each then on_each(i, #to_run) end
    if pending == 0 then on_done(panel_state.test_cases) end
  end)
end

execute.run already uses vim.uv async I/O, so spawning multiple processes concurrently is safe. The panel render should handle partial updates as results arrive — which it already does since each test case's state is updated independently before re-rendering.

A config option parallel_tests = true (default true) would allow opt-out for systems with tight resource constraints.

Alternatives considered

Keeping sequential execution. This is simpler but meaningfully slower for problems with 5-10 test cases, which is common after using :CP edit to add custom cases.

## Problem `run_all_test_cases` in `lua/cp/runner/run.lua` runs test cases sequentially via a recursive `run_next` callback. For problems with many test cases (e.g., 10+ after editing), this is significantly slower than necessary. Test cases are fully independent and there is no reason to serialize them. ## Proposed solution Run all test cases concurrently using a counter-based completion barrier: ```lua local pending = #to_run for i, idx in ipairs(to_run) do M.run_test_case(idx, debug, function() pending = pending - 1 if on_each then on_each(i, #to_run) end if pending == 0 then on_done(panel_state.test_cases) end end) end ``` `execute.run` already uses `vim.uv` async I/O, so spawning multiple processes concurrently is safe. The panel render should handle partial updates as results arrive — which it already does since each test case's state is updated independently before re-rendering. A config option `parallel_tests = true` (default true) would allow opt-out for systems with tight resource constraints. ## Alternatives considered Keeping sequential execution. This is simpler but meaningfully slower for problems with 5-10 test cases, which is common after using `:CP edit` to add custom cases.