openshift / openshift/rosa

Standardize test seams for ROSA CLI commands

Open
#3,383 0 comments 0 reactions 1 assignee View on GitHub

@amandahla is already working on this.

Since Jul 16, 2026.

Dominant language
Go
Stars
103
Forks
257
Avg merge
2d 21h
Merged PRs (30d)
43

Description

Summary

Standardize the testability pattern used by ROSA CLI command packages under cmd/ so future coverage work does not introduce multiple dependency-injection conventions.

cmd/initialize/cmd.go currently uses an explicit initDeps / defaultInitDeps() dependency bundle. Other commands generally use runWithRuntime(*rosa.Runtime) with runtime mocks, or package-level function-variable seams (for example, cmd/download/oc) that tests temporarily override and restore.

This follow-up is intentionally separate from the test-coverage work in #3368.

Rationale

A single, documented convention will reduce cognitive overhead and make command implementations and tests easier to maintain consistently.

Affected areas

  • cmd/initialize/cmd.go
  • Existing command packages that need seams not represented by *rosa.Runtime
  • Command testing guidance and examples, as appropriate

Required changes

  1. Agree on the preferred command test-seam pattern for dependencies outside *rosa.Runtime.
  2. Refactor cmd/initialize to the agreed pattern, if appropriate.
  3. Apply the agreed pattern to comparable command packages where doing so improves consistency.
  4. Ensure tests that override package-level variables restore their original values to prevent cross-test interference.

Acceptance criteria

  • A documented and consistently applied convention exists for command-level test seams.
  • cmd/initialize follows that convention or has a documented exception.
  • Relevant tests remain deterministic and do not leak modified global state.
  • Targeted tests and the repository's standard Go verification commands pass.

Context

Requested by @amandahla.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.