Capturing console output in Go tests

Ideally, every function that writes to the stdout probably should ask for a io.Writer and write to it instead. However, it's common to encounter functions like this: This would be easier to test if frobnicate would ask for a writer to write to. For instance: You could pass os.Stdout to frobnicate explicitly to write to the console: This behaves exactly the same way as the first version of frobnicate. During test, instead of os.Stdout, you'd just pass a bytes.Buffer and assert its content as follows: This is all good. But many functions or methods that emit logs just do that directly to stdout. So we want to test the first version of frobnicate without making any changes to it. I found this neat pattern to test functions that write to stdout without accepting a writer. The idea is to write a helper function named captureStdout that looks like this: Here's what's happening under the hood: We use os.Pipe() to create a pipe: a connected pair of file descriptors - a reader (r) and a writer (w). Think of it like a temporary tunnel. Whatever we write to w, we can read back from r. Since both are just files as far as Go is concerned, we can temporarily replace os.Stdout with the writer end of the pipe: This means anything printed to stdout during the function run actually goes into our pipe. After the function runs, we close the writer to signal that we're done writing, then read from the reader into a buffer and restore the original stdout. Now we can test frobnicate without touching its implementation: No need to refactor frobnicate. This works great for quick tests when you don't control the code or just want to assert some printed output. A more robust capture out The above version of captureStdout works fine for simple cases. But in practice, functions might also write to stderr, especially if they're using Go's log package or if a panic happens. For example, this would not be captured by the simple captureStdout helper: Even though it looks like a normal print statement, log writes to stderr by default. So if you want to catch that output too, or generally capture everything that's printed to the console during a function call, we need to upgrade our helper a bit. I found this example from [immudb's captureOutput helper]. Here's a more complete version: This version does a few more things: - Captures everything: It redirects both os.Stdout and os.Stderr to ensure all standard output streams are captured. It also explicitly redirects the standard log package's output, which often bypasses os.Stderr. - Prevents deadlocks: Output is read concurrently in a separate goroutine. This is crucial because if f generates more output than the internal pipe buffer can hold, writing would block without a concurrent reader, causing a deadlock. - Ensure reader readiness: A sync.WaitGroup guarantees the reading goroutine is active before f starts executing. This prevents a potential race condition where initial output could be lost if f writes before the reader is ready. - Guarantees cleanup: Using defer, the original os.Stdout and os.Stderr are always restored, even if f panics. This prevents the function from permanently altering the program's standard output streams. You'd use captureOut the same way as the naive captureStdout. This version is safer and more complete, and works well when you're testing CLI commands, log-heavy code, or anything that might write to the terminal in unexpected ways. It's not a replacement for writing functions that accept io.Writer, but when you're dealing with existing code or want to quickly assert on terminal output, it gets the job done. [immudb's captureOutput helper]: https://github.com/codenotary/immudb/blob/cf9a5d8b9b4d3784c6b9fa8c874902bf1318a6e8/cmd/immuclient/immuclienttest/helper.go#L143