Go CLI Testing
Test observable behavior at the narrowest boundary that proves it. Isolate every
mutable resource and reserve executable tests for process-level semantics.
Core Workflow
- Inventory success, invalid, boundary, dependency-failure, and cancellation behavior.
- Map each case to a pure, command, adapter, integration, or binary test.
- Inject arguments, streams, configuration, clocks, and effectful dependencies.
- Isolate files, environment, servers, repositories, ports, and subprocesses.
- Assert stdout, stderr, exit behavior, and errors according to the public contract.
- Gate live or platform-specific tests and make their changes reversible.
- Run standard, race, tagged, and relevant platform checks.
- Execute every supported build profile and smoke-test final artifacts.
- Interpret coverage gaps without treating execution as behavioral proof.
Read Next
| Task |
Load |
| Build or overhaul a CLI test suite |
guidelines.md, workflows/test-cli-command.md |
| Stabilize a flaky asynchronous test |
workflows/stabilize-flaky-test.md |
| Write focused command tests |
references/cli-testing/rules.md, references/cli-testing/examples.md |
| Add subprocess, HTTP, repository, or integration tests |
references/cli-testing/patterns.md |
| Review coverage, isolation, or flakiness |
references/cli-testing/checklist.md |
| Choose the right test boundary |
references/cli-testing/knowledge.md |
| Benchmark or profile performance |
Use go-performance-testing |
Guardrails
- Do not mutate developer data or depend on fixed temporary paths and ports.
- Do not run parallel tests that replace process-global state.
- Replace timing sleeps with synchronization, deadlines, or fake clocks.
- Use
testing/synctest only when the minimum Go version supports it and the
behavior fits an isolated bubble.
- Inspect wrapped errors structurally unless exact diagnostics are contractual.
- Prefer one valuable executable flow over many slow end-to-end tests.
- Construct a fresh command tree and typed configuration for every test.
- Assert both
Execute errors and stream output.
Source Notes
Guidance is transformed and paraphrased from testing material throughout
Ricardo Gerardi, Powerful Command-Line Applications in Go (Pragmatic
Bookshelf, 2021), especially Chapters 1-7 and 11. Examples are original.
Book: https://pragprog.com/titles/rggo/powerful-command-line-applications-in-go/
Modern test APIs should be verified against https://pkg.go.dev/testing and the
current Go documentation before implementation.
Fresh command-tree, HTTP fake, configuration, and build-profile guidance also
incorporates transformed material from Marian Montagnino, Building Modern CLI
Applications in Go (Packt, 2023), especially Chapters 4, 6, and 11.
Subtest, coverage, parser, concurrency, HTTP server, and SQL adapter guidance
also incorporates transformed material from Inanc Gumus, Go by Example:
Programmer's Guide to Idiomatic and Testable Programs (Manning, 2025),
Chapters 2-10.
Test categorization, race/shuffle execution, deterministic time, iotest, and
benchmark-correctness guidance also incorporates transformed material from
Teiva Harsanyi, 100 Go Mistakes and How to Avoid Them (Manning, 2022),
Chapter 11.
1---2name: go-cli-testing3description: Design, implement, stabilize, and review Go CLI tests across fresh command trees, pure logic, table-driven cases, streams, typed configuration, files, environment, function-backed HTTP fakes, repositories, subprocesses, capability profiles, race checks, and artifact behavior. Use when adding command tests, diagnosing flaky Go tests, choosing test boundaries, or verifying human-, agent-, and CI-facing CLI contracts.4license: MIT5---67# Go CLI Testing89Test observable behavior at the narrowest boundary that proves it. Isolate every10mutable resource and reserve executable tests for process-level semantics.1112## Core Workflow13141. Inventory success, invalid, boundary, dependency-failure, and cancellation behavior.152. Map each case to a pure, command, adapter, integration, or binary test.163. Inject arguments, streams, configuration, clocks, and effectful dependencies.174. Isolate files, environment, servers, repositories, ports, and subprocesses.185. Assert stdout, stderr, exit behavior, and errors according to the public contract.196. Gate live or platform-specific tests and make their changes reversible.207. Run standard, race, tagged, and relevant platform checks.218. Execute every supported build profile and smoke-test final artifacts.229. Interpret coverage gaps without treating execution as behavioral proof.2324## Read Next2526| Task | Load |27|---|---|28| Build or overhaul a CLI test suite | `guidelines.md`, `workflows/test-cli-command.md` |29| Stabilize a flaky asynchronous test | `workflows/stabilize-flaky-test.md` |30| Write focused command tests | `references/cli-testing/rules.md`, `references/cli-testing/examples.md` |31| Add subprocess, HTTP, repository, or integration tests | `references/cli-testing/patterns.md` |32| Review coverage, isolation, or flakiness | `references/cli-testing/checklist.md` |33| Choose the right test boundary | `references/cli-testing/knowledge.md` |34| Benchmark or profile performance | Use `go-performance-testing` |3536## Guardrails3738- Do not mutate developer data or depend on fixed temporary paths and ports.39- Do not run parallel tests that replace process-global state.40- Replace timing sleeps with synchronization, deadlines, or fake clocks.41- Use `testing/synctest` only when the minimum Go version supports it and the42 behavior fits an isolated bubble.43- Inspect wrapped errors structurally unless exact diagnostics are contractual.44- Prefer one valuable executable flow over many slow end-to-end tests.45- Construct a fresh command tree and typed configuration for every test.46- Assert both `Execute` errors and stream output.4748## Source Notes4950Guidance is transformed and paraphrased from testing material throughout51Ricardo Gerardi, *Powerful Command-Line Applications in Go* (Pragmatic52Bookshelf, 2021), especially Chapters 1-7 and 11. Examples are original.5354Book: https://pragprog.com/titles/rggo/powerful-command-line-applications-in-go/5556Modern test APIs should be verified against https://pkg.go.dev/testing and the57current Go documentation before implementation.5859Fresh command-tree, HTTP fake, configuration, and build-profile guidance also60incorporates transformed material from Marian Montagnino, *Building Modern CLI61Applications in Go* (Packt, 2023), especially Chapters 4, 6, and 11.6263Subtest, coverage, parser, concurrency, HTTP server, and SQL adapter guidance64also incorporates transformed material from Inanc Gumus, *Go by Example:65Programmer's Guide to Idiomatic and Testable Programs* (Manning, 2025),66Chapters 2-10.6768Test categorization, race/shuffle execution, deterministic time, `iotest`, and69benchmark-correctness guidance also incorporates transformed material from70Teiva Harsanyi, *100 Go Mistakes and How to Avoid Them* (Manning, 2022),71Chapter 11.
LVTD-LLC