Add test cases for different ProcessorSlot

[cdfive]

Describe what this PR does / why we need it

Add some test cases for different ProcessorSlot, NodeSelectorSlot,ClusterBuilderSlot and so on.

Does this pull request fix one issue?

Related to #580

Describe how you did it

• Add testFireEntry method for each Slot to verify fireEntry method has been called in entry method,
  and called only once.

• Add testFireExit method for each Slot to verify fireExit method has been called in exit method,
  and called only once.

• Add some test cases to test the interactions in entry method, by mocking and verify the interaction
  of Node and Slot.

Describe how to verify it

Run the test cases.

Special notes for reviews

The ClusterNodeBuilderTest is renamed to ClusterBuilderSlotTest for more standard test Class name.

The DegradeSlot and SystemSlot using static method to check the rules:
DegradeRuleManager.checkDegrade(resourceWrapper, context, node, count);
SystemRuleManager.checkSystem(resourceWrapper);,
while FlowSlot and AuthoritySlot call the internal method.

Maybe they can be unified in the furture.
I think using static method in XxxRuleManager is better, since it makes the slot class more testable,
and we can write separate test cases for XxxRuleManager.
This is a suggestion, they're not modified yet.

[sczyh30]

Thanks for contributing.

Maybe they can be unified in the future.
I think using static method in XxxRuleManager is better, since it makes the slot class more testable,
and we can write separate test cases for XxxRuleManager.

IMHO, XxxRuleManager is used for managing rules (update / get rules), not for rule checking. In legacy design, the rule checking logic is located in Rule#passCheck method, which will be deprecated and removed later. Maybe it's better to move all checkXxx methods to each slot? Discussions are welcomed.

[cdfive]

XxxRuleManager is used for managing rules (update / get rules), not for rule checking
Maybe it's better to move all checkXxx methods to each slot.

Oh, I see. Previously I just found the implement way is different in four slots, and thought unified may be better.

I agree with you, the XxxRuleManager is used for managing rules (update / get rules)，as the class name indicates its responsibility.

How about move checkXxx method in XxxRuleChecker class,
like FlowRuleChecker and FlowRuleCheckerTest.

In slot entry method, just call XxxRuleChecker.checkXxx() and fireEntry, make the slot code simple and clear, and easy to test.
Then in XxxRuleChecker.checkXxx() method, call XxxRuleManager to get all rules and do checkRule logic for each rule, and we can add separate test cases for XxxRuleChecker and XxxRuleManager.

[codecov-io]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 42.48%. Comparing base (c14e329) to head (77059ce).
Report is 397 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master     #598      +/-   ##
============================================
+ Coverage     42.25%   42.48%   +0.23%     
- Complexity     1419     1428       +9     
============================================
  Files           307      307              
  Lines          8894     8894              
  Branches       1203     1203              
============================================
+ Hits           3758     3779      +21     
+ Misses         4677     4658      -19     
+ Partials        459      457       -2     

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

[sczyh30]

Could you please resolve the conflicts? :)

[CLAassistant]

All committers have signed the CLA.