Add InterpretReplica test case for CloneSet

[Abhay349]

What this PR does

Adds a test case for InterpretReplica of CloneSet under third-party resource customizations.

Why we need it

• Improves test coverage for Kruise CloneSet
• Ensures replica interpretation behavior is verified and stable

Notes

• InterpretReplica for CloneSet returns a scalar replica count (int64),
  consistent with existing interpreter behavior.

[gemini-code-assist]

Summary of Changes

Hello @Abhay349, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request focuses on bolstering the testing framework for Kruise CloneSet by introducing a dedicated test case. The primary goal is to validate the InterpretReplica function's behavior when interacting with third-party resource customizations, thereby ensuring the accuracy and stability of replica interpretation. This enhancement contributes to a more robust and reliable system.

Highlights

• New Test Case: A new test case has been added for the InterpretReplica function within CloneSet under third-party resource customizations.
• Improved Test Coverage: This PR enhances the test coverage for Kruise CloneSet, specifically for its replica interpretation logic.
• Behavior Verification: The new test ensures that the replica interpretation behavior is correctly verified and remains stable.
• Expected Output Defined: The interpretreplica-test.yaml file now explicitly defines the expected output for the InterpretReplica operation, setting the replica count to 4.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[karmada-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign yike21 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• pkg/resourceinterpreter/default/thirdparty/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[gemini-code-assist]

Code Review

This pull request adds a test case for the InterpretReplica operation on CloneSet resources, which is a good addition for test coverage. The change correctly asserts the replica count. My feedback focuses on making this new test case more comprehensive by also validating the resource requirements, which would lead to a more robust test.

[gemini-code-assist]

While this test correctly validates the replica count, it could be more comprehensive. The GetReplicas Lua function in customizations.yaml for CloneSet returns both replica and requirement. This test only validates the replica.

To improve test coverage, please consider also validating the requirement output. This would ensure that kube.accuratePodRequirements(obj.spec.template) is correctly interpreting fields like affinity and tolerations from the CloneSet's pod template.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 46.62%. Comparing base (9ba7dc0) to head (40ca714).
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #7019      +/-   ##
==========================================
+ Coverage   46.60%   46.62%   +0.02%     
==========================================
  Files         699      699              
  Lines       48182    48182              
==========================================
+ Hits        22453    22463      +10     
+ Misses      24032    24024       -8     
+ Partials     1697     1695       -2     

Flag	Coverage Δ
unittests	46.62% <ø> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Abhay349]

The failing init e2e test jobs appear unrelated to this change.

This PR only adds a test case for InterpretReplica of CloneSet and does not modify any runtime or controller logic.

All relevant unit tests and validation checks are passing locally and in CI.

[XiShanYongYe-Chang]

Hi @Abhay349, One of the testing objectives we aim to achieve is the ability to design multiple test cases that cover the logic under test, similar to writing unit tests. This can be accomplished using orthogonal testing methods.

You can refer to #6991 and #7012 (comment)

[Abhay349]

Hi @XiShanYongYe-Chang, thanks a lot for the clarification and for sharing the references to #6991 and #7012. That really helped me understand the expected direction better.

I now understand that the aim of this umbrella issue is to design orthogonal test cases, where each interpreter operation is tested independently, similar to how we write unit tests.

In this PR, I have focused only on InterpretReplica for CloneSet as an initial incremental step. I added explicit output verification in interpretreplica-test.yaml to validate the replica interpretation logic in isolation and align it with the expected testing structure.

Based on your guidance, I’m planning to continue adding output verification for the remaining CloneSet operations as follow-up work.

Please let me know if this incremental approach is okay, and I’ll proceed accordingly, either by extending this PR or by raising separate follow-up PRs for the remaining test cases, as you prefer.

Thanks again for the guidance 🙏

[XiShanYongYe-Chang]

Could you directly modify this PR by completing all the clonset tests?

[Abhay349]

Hi @XiShanYongYe-Chang

I’ve updated this PR to complete all CloneSet interpreter tests with output verification:

• InterpretReplica
• InterpretHealth
• InterpretDependency
• InterpretStatus
• AggregateStatus
• ReviseReplica

Please let me know if any further changes are needed.
Thanks a lot for your guidance .

[XiShanYongYe-Chang]

Thanks, the number of test files is as expected.

For each test file, or rather each operation, it is still not enough. We need to add sufficient test cases to cover the logic being tested. Therefore, a test file should ideally contain multiple test cases.

[Abhay349]

Thanks for the clarification, that makes sense.
To make sure I’m aligning with expectations and not over- or under-testing:
for each operation, would 2–3 representative test cases (covering happy path + key edge cases) be sufficient, or would you prefer broader coverage?

I’ll proceed accordingly once confirmed.
Thanks!

[XiShanYongYe-Chang]

karmada/pkg/resourceinterpreter/default/thirdparty/resourcecustomizations/apps.kruise.io/v1alpha1/CloneSet/customizations.yaml

Lines 10 to 17 in 9ba7dc0

	replicaResource:
	luaScript: >
	local kube = require("kube")
	function GetReplicas(obj)
	replica = obj.spec.replicas
	requirement = kube.accuratePodRequirements(obj.spec.template)
	return replica, requirement
	end

The number of test cases is not a fixed requirement; it only needs to cover the logic being tested. For example, in the case of Clonset's replicaResource, since there is no if branch, just one test case is sufficient.

[Abhay349]

I understand that the goal is not to hit a specific number of test cases, but to ensure the logic is fully covered. For operations like replicaResource, where the logic is straight-through with no conditional branches, a single test case is sufficient.

For operations that do contain branching logic (for example InterpretHealth and AggregateStatus), I’ll add additional test cases to cover the different paths in the logic, rather than adding redundant cases elsewhere.

I’ll update this PR accordingly to improve branch-level coverage where it’s meaningful.
Thanks again for the guidance.