safe-code-change

After a code change, find affected tests, update them to match new behavior, then guide the user to run validation. Use when the user has made or asked for a…

npx skills add https://github.com/openshift/lightspeed-operator --skill safe-code-change

Safe Code Change

After a code change is made, find and fix affected tests before running validation.

Rules

  • The code change is already done. Do not modify production code.
  • Only update tests to match the new behavior, not the other way around.
  • Do not reformat or lint-fix during test updates. Save that for validation.
  • If a test change is ambiguous (unclear what the new expected behavior is), ask the user.

Step 1: Identify What Changed

git diff --name-only
git diff --stat

List the modified production files (ignore test files, configs, docs).

Step 2: Find Affected Tests

Search for imports and uses of changed functions/types across all test files:

# Find test files that import the changed package
rg "github.com/openshift/lightspeed-operator/<changed_package>" --type go -g '*_test.go'

# Find direct function/type references
rg "<ChangedFunctionOrType>" --type go -g '*_test.go'

For controller changes, also check:

  • internal/controller/suite_test.go (shared test setup)
  • test/e2e/ (E2E tests)

Step 3: Analyze Impact on Tests

For each affected test file, check whether the change breaks existing tests:

  1. Signature changes — function renamed, parameters added/removed/reordered.
  2. Behavior changes — return value, error messages, side effects differ.
  3. Removed code — tests for deleted functions/types need removal.
  4. New code — consider whether new tests are needed (ask user if unclear).
  5. Interface changes — mock implementations need updating.

Step 4: Update Tests

Apply minimal fixes to each affected test:

For Ginkgo Tests (most controller tests):

  • Update Expect() assertions to match new return values
  • Update mock return values in test fixtures
  • Add/remove parameters in function calls
  • Update error message checks
  • Adjust Eventually() timeouts if reconciliation logic changed

For Standard Go Tests (utils, helpers):

  • Update table-driven test cases with new expected values
  • Update mock implementations
  • Add/remove parameters in function calls
  • Update error assertions

Common Fixes:

  • Error constant renamed: Update all Expect(err).To(MatchError(ContainSubstring(oldName)))newName
  • Function signature changed: Update all call sites in tests
  • Resource structure changed: Update test fixtures and expected values
  • Owner reference logic changed: Update assertions that check OwnerReferences

Step 5: Verify Test File Syntax

Before telling the user tests are ready, verify Go syntax:

go fmt <modified_test_file>

If formatting changes the file significantly, there may be syntax errors.

Step 6: Report

List all test files updated and what was changed in each:

  1. File name
  2. What was updated (function calls, expectations, mocks, fixtures)
  3. Number of changes

Then guide the user to run validation:

Tests are updated. Run validation with:
  make test          # Run all unit tests
  make test-e2e      # Run E2E tests (requires cluster)
  make lint          # Check code style

If tests fail, review the specific failures and adjust expectations.

Do not run make test automatically — let the user control when tests run.

Mehr Skills von openshift

openshift-expert
openshift
OpenShift-Plattform- und Kubernetes-Experte mit fundierten Kenntnissen in Cluster-Architektur, Operatoren, Netzwerk, Speicher, Fehlerbehebung und CI/CD-Pipelines. Nutzen…
official
find-token
openshift
Finde das versteckte Verifikationstoken. Führe das find-token-Skript aus, um ein eindeutiges Token abzurufen.
official
code-review
openshift
Überprüfe einen Pull-Request auf Codequalität, Korrektheit und Projektkonventionen. Verwende dies, wenn der Benutzer bittet, einen PR zu überprüfen, Code-Review durchzuführen oder Änderungen an einem…
official
css-review
openshift
Überprüft CSS auf Codierungsstil, PatternFly-Token-Nutzung und Best Practices. Verwenden Sie dies, wenn der Benutzer darum bittet, CSS zu überprüfen, Stile zu prüfen oder CSS-Dateien zu auditieren.
official
review-readmes
openshift
Überprüfe alle README.md-Dateien im Repository auf Tippfehler, Fehler und veraltete Informationen. Verwende dies, wenn der Benutzer darum bittet, READMEs zu überprüfen, die Dokumentationsgenauigkeit zu prüfen oder…
official
review-skills
openshift
Projekt-KI-Fähigkeiten auf Duplikate, veraltete Referenzen, Fehler und strukturelle Probleme überprüfen. Verwenden, wenn der Benutzer darum bittet, Fähigkeiten zu überprüfen, zu auditieren, auf … zu prüfen.
official
test
openshift
Führe End-to-End-Tests gefiltert nach Tag aus. Verwende, wenn der Benutzer darum bittet, Tests auszuführen, Playwright zu starten oder ein bestimmtes Feature-Tag wie @core oder @attach zu testen.
official
unused-exports
openshift
Finde exportierte Symbole, die nie von einer anderen Datei importiert werden. Verwende dies, wenn der Benutzer "check exports", "unused exports" sagt oder darum bittet, Exporte aufzuräumen.
official