openshift/check-test-coverage
Analyze oc-mirror CLI feature coverage across integration and e2e tests, identifying untested features and gaps
npx skills add https://github.com/openshift/oc-mirror --skill check-test-coverage
Analyze which oc-mirror CLI features are tested at the integration and e2e levels, and which have gaps.
Run these commands to enumerate all subcommands and flags:
oc-mirror --v2 --help
oc-mirror --v2 delete --help
oc-mirror --v2 list operators --help
oc-mirror --v2 list releases --help
oc-mirror --v2 version --help
If oc-mirror is not in PATH, build it first with make build and use ./bin/oc-mirror.
From the output, extract:
Read all *_test.go files in tests/integration/. For each file, extract:
Describe, Context, and It block labels--dry-run, --delete-id, --from)Build a map of feature -> test file + test label.
Read test files in tests/e2e/test/e2e/ (primarily oc_mirror_v2.go). Extract:
tests/e2e/test/e2e/testdata/For each CLI feature (subcommand, flag, workflow), classify coverage:
| Level | Meaning |
|-------|---------|
| Covered | Tested at integration and/or e2e level with meaningful assertions |
| Partially covered | Only happy path, or tested at only one level when both would be appropriate |
| Not covered | No test exercises this feature |
Consider a feature "partially covered" if:
Present results in this format:
| Feature / Flag | Integration | E2E | Status |
|----------------------|-------------|------|------------------|
| m2m workflow | m2m_test.go | 73359| Covered |
| --dry-run | dry_run_... | - | Partially covered|
| --secure-policy | - | - | Not covered |
| ... | | | |
List the top uncovered or partially covered features, ordered by importance:
For each gap, recommend:
If a previous coverage report exists in the conversation history, highlight what changed: new tests added, features that moved from "not covered" to "covered", and any regressions.
Take openshift/check-test-coverage from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.