safe-code-change

โดย openshift

หลังจากมีการเปลี่ยนแปลงโค้ด ให้ค้นหาการทดสอบที่ได้รับผลกระทบ อัปเดตให้สอดคล้องกับพฤติกรรมใหม่ จากนั้นแนะนำผู้ใช้ให้รันการตรวจสอบความถูกต้อง ใช้เมื่อผู้ใช้ได้ทำหรือขอให้มีการเปลี่ยนแปลงโค้ด...

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.

Skills เพิ่มเติมจาก openshift

openshift-expert
openshift
ผู้เชี่ยวชาญด้านแพลตฟอร์ม OpenShift และ Kubernetes ที่มีความรู้เชิงลึกเกี่ยวกับสถาปัตยกรรมคลัสเตอร์ โอเปอเรเตอร์ เครือข่าย พื้นที่จัดเก็บข้อมูล การแก้ไขปัญหา และไปป์ไลน์ CI/CD ใช้…
official
find-token
openshift
ค้นหาโทเค็นการยืนยันที่ซ่อนอยู่ รันสคริปต์ find-token เพื่อดึงโทเค็นที่ไม่ซ้ำกัน
official
code-review
openshift
ตรวจสอบ pull request เพื่อดูคุณภาพโค้ด ความถูกต้อง และความสอดคล้องกับข้อกำหนดของโปรเจกต์ ใช้เมื่อผู้ใช้ขอให้ตรวจสอบ PR, ตรวจสอบโค้ด หรือตรวจสอบการเปลี่ยนแปลงใน...
official
css-review
openshift
ตรวจสอบ CSS สำหรับรูปแบบการเขียนโค้ด การใช้โทเค็น PatternFly และแนวปฏิบัติที่ดีที่สุด ใช้เมื่อผู้ใช้ขอให้ตรวจสอบ CSS ตรวจสอบสไตล์ หรือตรวจสอบไฟล์ CSS
official
review-readmes
openshift
ตรวจสอบไฟล์ README.md ทั้งหมดใน repo เพื่อหาคำผิด ข้อผิดพลาด และข้อมูลที่ล้าสมัย ใช้เมื่อผู้ใช้ขอให้ตรวจสอบ README ตรวจสอบความถูกต้องของเอกสาร หรือ…
official
review-skills
openshift
ตรวจสอบทักษะ AI ของโครงการเพื่อหาความซ้ำซ้อน การอ้างอิงที่ล้าสมัย ข้อผิดพลาด และปัญหาเชิงโครงสร้าง ใช้เมื่อผู้ใช้ขอให้ตรวจสอบทักษะ ตรวจสอบทักษะ ตรวจสอบหา…
official
test
openshift
รันการทดสอบแบบ end-to-end ที่กรองตามแท็ก ใช้เมื่อผู้ใช้ขอให้รันการทดสอบ รัน Playwright หรือทดสอบฟีเจอร์เฉพาะแท็ก เช่น @core หรือ @attach
official
unused-exports
openshift
ค้นหาสัญลักษณ์ที่ถูกส่งออกแต่ไม่เคยถูกนำเข้าโดยไฟล์อื่น ใช้เมื่อผู้ใช้พูดว่า "ตรวจสอบการส่งออก" "ส่งออกที่ไม่ได้ใช้" หรือขอให้ทำความสะอาดการส่งออก
official