opencode: Skill for OpenCode

Fast, Reliable Unit Tests

CI runs bun turbo test --affected --concurrency=3 on 4-vCPU Linux and Windows runners (unit job in .github/workflows/test.yml), so each suite shares the CPU with two others, and Windows is the slower leg. Most slow or flaky unit tests here wait on real time, spawn too many processes, or assert wall-clock speed.

Read these first; this skill does not repeat them:

• Root AGENTS.md: the Testing and Style Guide sections.
• packages/app/AGENTS.md Tests (packages/desktop and packages/gui-extensions follow it): one owner per contract, and no production seams for tests.
• packages/ai/AGENTS.md: cassettes. The effect skill: it.effect and it.live.

Sibling skills: tui-tests (OpenTUI renderer tests in tui and cli), app-e2e-tests (Playwright in packages/app/e2e), component-tests (Storybook Playwright). This skill owns cli subprocess and service tests.

Know the budget

• Bun's default per-test timeout is 5000ms. Check the package's test script:
  • 30s: ai, cli, desktop, http-recorder, latex, merman, simulation, theme and tui pass --timeout 30000; core's script/test.ts passes --timeout=30000.
  • 5s: client, httpapi-codegen and sdk pass --timeout 5000; app, codemode, function, gui-extensions, plugin, plugin-browser, script, server, session-ui, ui and util use the default.
• Size Windows risk by counting spawns, not by local wall time.
  • npm.test.ts "installs a Git package from an npm ::path: subdirectory at a branch" takes 0.4s locally and hit 5000ms on Windows CI. Each Npm.add Git case makes about 75 git process events: 3 clone --recurse-submodules, which run the git-submodule shell script.
  • Assume roughly 40ms per Git-for-Windows spawn (estimated from an earlier git.test run on Windows CI: ~24s for 564 spawns). Some core file groups run 5-9x slower on Windows than locally.
  • Those test.each cases (npm.test.ts:223, :251) hit 5000ms in 13 of 45 Windows core runs; that is why core's runner now defaults to 30s (comment at packages/core/script/test.ts:38).
• A timeout loosens the budget only when it exceeds the package default.
  • In a 5s package, work that legitimately needs longer gets a per-test timeout and a comment naming the work: packages/server/test/fetch.test.ts:406-407 ("Real retries wait 18 * 200 ms ...", { timeout: 10_000 }). test.each(table)(name, fn, 30_000) takes it as the third argument. Use file-wide setDefaultTimeout only when every test in the file does such work.
  • In core, the four file-level setDefaultTimeout(30_000) calls only restate the runner default, and a per-test { timeout: 15_000 } (still in tool-shell.test.ts, session-generate.test.ts and others) is stricter than it. Do not add values at or below 30s there.
• Never absorb a sleep, poll or production interval with a larger timeout, --retry, or skipIf(win32); remove the wait. Skip on Windows only when the platform lacks the capability, with a comment (npm.test.ts:313, symlinks).