How do opencode write tests for their TUI?

How do opencode write tests for their tui

OpenCode tests their TUI (Terminal User Interface) through a combination of unit testing for core logic, utility-specific tests, and a decoupled architecture that facilitates manual and integration testing.

Based on the codebase, here are the primary ways they handle TUI testing:

###1. Unit Testing Underlying Logic

The TUI is primarily a view layer over complex state management (sessions, permissions, tools, and configurations). Instead of testing the UI components directly, OpenCode focuses heavily on testing the underlying logic in packages/opencode/test/.

• Permissions: packages/opencode/test/permission/next.test.ts tests the "ask/reply" flow that the TUI uses to prompt users for tool execution.
• Sessions: packages/opencode/test/session/session.test.ts ensures that events (which the TUI listens to) are emitted correctly.
• Tools: Tests in packages/opencode/test/tool/ verify that the terminal-based tools behave correctly before they ever reach the UI.

###2. Transcript & Formatter Testing

Since the TUI is text-heavy, OpenCode tests the "transcripts" (the text representation of a conversation).

• File: packages/opencode/test/cli/tui/transcript.test.ts
• Method: They test functions like formatAssistantHeader, formatPart, and formatTranscript to ensure that metadata (cost, tokens, time) and reasoning blocks are formatted correctly for terminal display.

###3. Decoupled TUI Architecture

The main TUI entry point (packages/opencode/src/cli/cmd/tui/app.tsx) is designed to be environment-agnostic. The tui function accepts optional injections:

export function tui(input: {
  url: string
  args: Args
  directory?: string
  fetch?: typeof fetch // Mockable fetch
  events?: EventSource // Mockable event source
  onExit?: () => Promise<void>
})

This allows the TUI to be run against a mock server or a recorded event stream, although current tests primarily use these hooks for manual debugging.

###4. Integration via API

OpenCode tests the API endpoints that drive the TUI. For example, packages/opencode/test/server/session-select.test.ts tests the /tui/select-session endpoint, which is used to control which session is currently active in the interface.

###5. Manual & Web-based Testing

Because the TUI is built using SolidJS and opentui, it can be rendered in different environments.

• Local Development: CONTRIBUTING.md suggests running bun dev in packages/opencode to test the TUI manually.
• Web Testing: The project includes a web app (packages/web) that mirrors much of the TUI logic, allowing developers to test UI changes in a browser environment using standard dev tools.

###Summary of Tools

• Test Runner: Bun Test
• UI Framework: SolidJS rendered via opentui.
• Testing Philosophy: High coverage on business logic/state transitions and low-to-no reliance on component-level snapshot testing for the terminal output.