Go

Stove can run a Go service as the application under test through process or container runners. The Kotlin test DSL keeps the same shape for registered systems; Go-specific work is build wiring, env/arg configuration, OTel SDK setup, and optional Kafka bridge integration.

Two modes, one DSL Process mode runs the Go binary for fast iteration. Container mode runs a Docker image for artifact-level parity. The same Kotlin tests can target either mode when StoveConfig branches on one option.

Full reference source: recipes/process/golang/go-showcase.

Pick a mode

🏃 Process mode

stove-process · goApp() · processApp()

• Fast local iteration
• Direct binary run, easiest debugging
• You manage host runtime alignment

Process mode guide →

🐳 Container mode

stove-container · containerApp()

• CI parity with production image
• Environment isolation
• Image build adds setup cost

Container mode guide →

Rule of thumb: start with process mode for fast feedback, add container mode in CI when you want image-level confidence. The runner changes; the external-surface assertions can stay the same.

What you get

🧱

External systems stay testable

HTTP, PostgreSQL, Kafka, MongoDB, Redis, and other registered systems use the same Kotlin-side DSL. The Go app must receive their connection details through env vars or CLI args.

🛰️

Distributed tracing

Spans from Go appear in the same trace tree as the test. Initialize the Go OTel SDK and enable Stove’s span receiver in the test setup.

📊

Dashboard streams

Go runs stream to the dashboard like any JVM run. Timelines, snapshots, Kafka explorer.

🤖

MCP triage

Failed Go runs queryable through stove CLI MCP server.

📨

Kafka assertions

shouldBePublished / shouldBeConsumed via the stove-kafka bridge. Sarama, franz-go, and segmentio/kafka-go have adapters; other clients can call the core bridge directly.

📈

Integration coverage

go build -cover + GOCOVERDIR collected on graceful shutdown. HTML + summary reports.

Adapting for other languages

Same shape, swap the Go-specific parts.

Part	Go	Python	Node.js	Rust
Build	go build	(none / pip install)	npm install && build	cargo build
AUT runner	goApp() / containerApp()	processApp() / containerApp()	processApp() / containerApp()	processApp() / containerApp()
OTel HTTP	otelhttp.NewHandler	opentelemetry-instrumentation-flask	@opentelemetry/instrumentation-http	tracing-opentelemetry
OTel DB	otelsql	opentelemetry-instrumentation-psycopg2	@opentelemetry/instrumentation-pg	tracing-opentelemetry
Kafka assertions	stove-kafka bridge	(bridge needed)	(bridge needed)	(bridge needed)

The Kotlin test side keeps the same shape. The AUT runner, config mapping, and language-specific instrumentation are the parts that differ.

Profiling support

Stove 0.28.0 (upcoming) adds native Go profiling through go/stove-profiler, a wrapper around Grafana's Go SDK. Configure DashboardExternalProfilingOptions, map the exposed settings into the Go process/container, and call stoveprofiler.StartFromEnv() with a deferred Close() in the application. Profiles reach the existing Stove Server and appear in Drill Down and MCP.

The Gradle stoveTracing.profiling plugin configures the JVM agent; Go profiling uses the native wrapper. See Go developers for the complete setup, HTTPS/authentication, graceful shutdown, supported metrics, and interpretation.