Isolate process-global mocks

When a test uses process-global/irreversible module mocking, prevent cross-test contamination by isolating the affected test files into separate `bun test` runs (batch isolation). Keep mocks narrowly scoped so tests don’t need to mock large dependency graphs, and avoid importing “config/provider” chains in units where tests shouldn’t require them.

copy reviewer prompt

Prompt

Reviewer Prompt
Deploy Agent

When a test uses process-global/irreversible module mocking, prevent cross-test contamination by isolating the affected test files into separate bun test runs (batch isolation). Keep mocks narrowly scoped so tests don’t need to mock large dependency graphs, and avoid importing “config/provider” chains in units where tests shouldn’t require them.

Practical checklist:

  • Prefer narrow mock.module() for the exact dependency that causes nondeterminism (e.g., config derived from developer machine).
  • If the runtime mocking mechanism is process-global, run the mocked test(s) in their own bun test <file> (or separate script/job) rather than grouping.
  • If mocking a dependency would require mocking an entire provider registry, refactor the unit to reduce import chain coupling (e.g., read minimal config directly or inject a loader so the unit under test can be exercised without pulling in the full provider stack).

Example (pattern):

// conversations.test.ts
mock.module('../config/config-loader', () => ({
  loadConfig: mock(async () => ({ assistant: 'claude' })),
}));

Then run it as an isolated invocation:

cd packages/core && bun test packages/core/src/db/conversations.test.ts

This ensures your tests remain deterministic and don’t break due to local .archon/config.yaml contents or prior mocked state from other test files.

Source discussions