Reason/Context
Why we need this improvement?
The upcoming LFX Term 2 2026 mentorship project — "Microcks-CLI v2 - IDE (VS Code) Integration and Local Dev Loop Enhancement" — will require the CLI to emit output to different destinations: a VS Code extension's output channel, GitHub Action log groups, and structured file output. Currently, cmd/test.go uses 14 hardcoded fmt.Printf/fmt.Println calls that write directly to os.Stdout, making it impossible to redirect or capture output programmatically.
How will this change help?
By threading an io.Writer through the test command, any consumer (VS Code extension, GitHub Action, unit test) can inject their own writer to capture output without parsing raw stdout text. The LFX mentee will be able to simply swap in a bytes.Buffer or a structured JSON writer on day one, instead of first having to refactor all 14 fmt.Printf call sites.
What is the motivation?
This is a pure preparatory refactor zero behavioral change that unblocks the LFX mentee from having to mix "output plumbing" work with their actual VS Code integration logic. It keeps the mentorship focused on the real deliverables.
Description
This refactoring replaces all fmt.Printf / fmt.Println calls in cmd/test.go with fmt.Fprintf(out, ...), where out is an injectable io.Writer that defaults to os.Stdout.
Before (hardcoded):
fmt.Printf("MicrocksClient got status for test \"%s\" - success: %s, inProgress: %s \n", ...)
fmt.Println("MicrocksTester waiting for 2 seconds before checking again or exiting.")
After (injectable):
fmt.Fprintf(out, "MicrocksClient got status for test \"%s\" - success: %s, inProgress: %s \n", ...)
fmt.Fprintln(out, "MicrocksTester waiting for 2 seconds before checking again or exiting.")
This is NOT a breaking change. The default writer is os.Stdout, so existing users see identical output. The only difference is that the writer is now swappable.
Scope clarification — this PR will NOT:
- ❌ Build the VS Code extension
- ❌ Add
--output=json or --output=junit support
- ❌ Build the GitHub Action
- ✅ Only thread
io.Writer through the test command and replace 14 print calls
Implementation ideas
- Add an
out io.Writer variable at the top of NewTestCommand's Run closure, defaulting to os.Stdout:
out := cmd.OutOrStdout() // Cobra's built-in writer support
- Replace all 14 fmt.Printf(...) and fmt.Println(...) calls with fmt.Fprintf(out, ...) and fmt.Fprintln(out, ...).
- Add a unit test that creates the command with a bytes.Buffer as output and verifies the test status messages appear in the buffer.
- Apply the same pattern to os.Exit(1) calls by wrapping them in a testable exit function (optional, can be a follow-up).
Reason/Context
Why we need this improvement?
The upcoming LFX Term 2 2026 mentorship project — "Microcks-CLI v2 - IDE (VS Code) Integration and Local Dev Loop Enhancement" — will require the CLI to emit output to different destinations: a VS Code extension's output channel, GitHub Action log groups, and structured file output. Currently,
cmd/test.gouses 14 hardcodedfmt.Printf/fmt.Printlncalls that write directly toos.Stdout, making it impossible to redirect or capture output programmatically.How will this change help?
By threading an
io.Writerthrough the test command, any consumer (VS Code extension, GitHub Action, unit test) can inject their own writer to capture output without parsing raw stdout text. The LFX mentee will be able to simply swap in abytes.Bufferor a structured JSON writer on day one, instead of first having to refactor all 14fmt.Printfcall sites.What is the motivation?
This is a pure preparatory refactor zero behavioral change that unblocks the LFX mentee from having to mix "output plumbing" work with their actual VS Code integration logic. It keeps the mentorship focused on the real deliverables.
Description
This refactoring replaces all
fmt.Printf/fmt.Printlncalls incmd/test.gowithfmt.Fprintf(out, ...), whereoutis an injectableio.Writerthat defaults toos.Stdout.Before (hardcoded):
After (injectable):
This is NOT a breaking change. The default writer is
os.Stdout, so existing users see identical output. The only difference is that the writer is now swappable.Scope clarification — this PR will NOT:
--output=jsonor--output=junitsupportio.Writerthrough the test command and replace 14 print callsImplementation ideas
out io.Writervariable at the top ofNewTestCommand'sRunclosure, defaulting toos.Stdout: