test: Refactored testSetCodeAndMsgUpdatesValuesCorrectly to use parameterized unit testing

[Monilnarang]

• I have registered the PR changes.

Ⅰ. Describe what this PR did

Summary:

• Parameterized testSetCodeAndMsgUpdatesValuesCorrectly and added more test cases.

Elaboration:

• The same method calls (getCode & getMsg()) would be repeated multiple times with different inputs, making the test harder to maintain and extend.
• When a test fails, JUnit only shows which assertion failed, but not which specific input caused the failure.
• Adding new test cases requires copying and pasting another Assertions.assertEquals(...) statement instead of simply adding new data.

To accomplish this, I have retrofitted the test into a parameterized unit test. This reduces duplication, allows easy extension by simply adding new value sets, and makes debugging easier as it clearly indicates which test failed instead of requiring a search through individual assertions.

Test execution results after changes:

Ⅱ. Does this pull request fix one issue?

Ⅲ. Why don't you add test cases (unit test/integration test)?

Ⅳ. Describe how to verify it

Successful tests run

Ⅴ. Special notes for reviews

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 54.51%. Comparing base (8c72b89) to head (e501b3b).

Additional details and impacted files

@@             Coverage Diff              @@
##                2.x    #7288      +/-   ##
============================================
- Coverage     54.52%   54.51%   -0.01%     
  Complexity     7303     7303              
============================================
  Files          1178     1178              
  Lines         41962    41962              
  Branches       4923     4923              
============================================
- Hits          22878    22874       -4     
- Misses        16914    16923       +9     
+ Partials       2170     2165       -5     

see 6 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[xingfudeshi]

LGTM

[slievrly]

@Monilnarang Could you resolve all the conflicts of the PRS you submitted?

[Monilnarang]

Thanks for the review @slievrly.
Resolved the conflicts.

[YongGoose]

IMHO, Enums are generally used for immutable objects.
If we use a setter on something like Code.SUCCESS as shown in the code below—setting it to 500 and Server error—it can create confusion for developers.

Code success = Code.SUCCESS;
success.setCode("500");
success.setMsg("Server error");

Therefore, while it's not directly related to this PR, I think it would be better to remove the setter from Code in a separate PR.

@xingfudeshi What do you think?