Testing

Relevant source files

This document covers the testing infrastructure, patterns, and conventions used in the oh-my-openagent codebase. It explains the test framework, file organization, CI execution strategy, and the use of isolation and mocking for complex system components.

Test Framework and CI Execution

The project utilizes Bun's built-in test runner (bun:test) for all unit and integration tests. The test suite is designed to run in a fast, concurrent environment while strictly checking TypeScript types.

Key Characteristics

Aspect	Implementation
Framework	`bun:test` (native Bun test runner) packages/omo-opencode/src/shared/live-server-route.test.ts1
Execution Engine	Bun (standardized via `bun-types`) test-setup.ts1
Global Setup	`test-setup.ts` (preloaded via `bunfig.toml`) bunfig.toml1-2
Loader Config	Treats `.md` files as text for prompt testing bunfig.toml5-6

Test Lifecycle Management

The test-setup.ts file provides a consistent baseline for every test execution by managing global state and environmental snapshots.

Global Resets: Clears singleton states for ClaudeSessionState, TaskToastManager, ModelFallbackState, and LiveServerRoute before and after each test test-setup.ts68-73 test-setup.ts107-110
Filesystem Cleanup: Automatically removes the OMO cache directory and rules injector storage to prevent cross-test data contamination test-setup.ts54-60 test-setup.ts66-67
Env Snapshotting: Captures process.env and the current working directory, restoring them after each test to prevent side effects test-setup.ts63-64 test-setup.ts79-96
Module Mocking: Integrates with installModuleMockLifecycle to ensure all mock.module calls are cleared between runs unless explicitly preserved test-setup.ts41-44 test-setup.ts114-117

Sources: test-setup.ts1-119 bunfig.toml1-7

Mock-Heavy Test Isolation

The codebase employs a "mock-heavy" approach for high-level orchestration, particularly within the plugin initialization flow. This allows verification of complex logic without spawning real background processes.

Plugin Module Dependency Injection

The createPluginModule function is designed for testability by accepting a PluginModuleDeps object, allowing tests to override any internal function packages/omo-opencode/src/testing/create-plugin-module.ts105-106

Initialization Flow: Verifies that the plugin correctly initializes the configuration context, sets up the live server route, and warms the server probe packages/omo-opencode/src/testing/create-plugin-module.ts109-132
Safety Checks: Validates that the plugin detects duplicate OMO installations or conflicting skill plugins before proceeding packages/omo-opencode/src/testing/create-plugin-module.ts116-125

Live Server Route Verification

The live-server-route.test.ts file demonstrates granular mocking of the fetch API and client objects to verify routing logic:

Identity Passthrough: Ensures that if a client is not the registered "in-process" client, it returns immediately without probing packages/omo-opencode/src/shared/live-server-route.test.ts75-92
Timeout Handling: Characterizes behavior when the live server probe fails to resolve, ensuring the system falls back to "in-process" within the PROBE_ABORT_MS window packages/omo-opencode/src/shared/live-server-route.test.ts179-195 packages/omo-opencode/src/shared/live-server-route.ts10

Natural Language to Code Entity Space: Live Route Resolution

Sources: packages/omo-opencode/src/shared/live-server-route.ts12-28 packages/omo-opencode/src/shared/live-server-route.ts85-129 packages/omo-opencode/src/shared/live-server-route.test.ts128-146

Integration Tests: Hash-Anchored Edits

Integration tests for the Hashline edit system are located in tests/hashline/. These tests verify the core code manipulation logic using the Vercel AI SDK and various model providers.

Test Structure

The hashline tests are organized into specific suites via package.json scripts:

test:basic: Standard edit operations (insert, delete, replace) tests/hashline/package.json8
test:edge: Complex scenarios like overlapping hashes or invalid line IDs tests/hashline/package.json9
test:multi: Verifies that the hashline logic remains consistent across different model families (OpenAI, Anthropic, etc.) tests/hashline/package.json10

Dependency Management

These tests run in an isolated workspace with specific dependencies on @ai-sdk/openai-compatible and zod for schema validation of model outputs tests/hashline/package.json13-17

Sources: tests/hashline/package.json1-19 tests/hashline/bun.lock1-37

QA and Smoke Testing

The codebase includes a suite of shell-based QA scripts in .agents/skills/opencode-qa/scripts/ that perform end-to-end smoke tests in isolated environments.

The Sandbox Model

To ensure QA runs do not pollute the user's actual environment, the common.sh helper provides oqa_mk_isolated_xdg .agents/skills/opencode-qa/scripts/lib/common.sh75-93

XDG Isolation: Redirects XDG_DATA_HOME, XDG_CONFIG_HOME, and HOME to a temporary directory .agents/skills/opencode-qa/scripts/lib/common.sh85-88
Port Management: Uses oqa_free_port to find available TCP ports for spawning test servers .agents/skills/opencode-qa/scripts/lib/common.sh96-105
Automatic Cleanup: Traps the EXIT signal to trigger oqa_cleanup, which kills spawned servers, tmux sessions, and removes temporary directories .agents/skills/opencode-qa/scripts/lib/common.sh151-175

Natural Language to Code Entity Space: QA Sandbox Lifecycle

Sources: .agents/skills/opencode-qa/scripts/lib/common.sh1-175