Delete ClusterQueue.ResourceGroups from cache_test

[gabesaba]

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

We removed the only test usage of this field in #2519 - see #2519 (comment). We are already ignoring it in the snapshot comparison.

Related to cleanup #2502

Special notes for your reviewer:

Does this PR introduce a user-facing change?

NONE

[gabesaba]

/assign @mimowo

[netlify]

✅ Deploy Preview for kubernetes-sigs-kueue ready!

Name	Link
🔨 Latest commit	b1fc27f
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-sigs-kueue/deploys/668b98ca2bd0db00086f8cf2
😎 Deploy Preview	https://deploy-preview-2545--kubernetes-sigs-kueue.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[mimowo]

LGTM, one question:

We removed the only usage of this field in #2519 - see #2519 (comment).

if all uses are removed, can we also remove the field itself?

[gabesaba]

LGTM, one question:

We removed the only usage of this field in #2519 - see #2519 (comment).

if all uses are removed, can we also remove the field itself?

sorry, I meant the only test usage in this file

/retest

[mimowo]

I see, so the current state is inconsistent since #1689 - the test cases specify the field, but it is ignored, we should definitely clean it up.

I'm yet wondering if it is preferable to drop the asserts or revert the ignoring. Can you provide some justification one way or another? It seems reasonable to assert cache fields in cache_test.

[gabesaba]

I see, so the current state is inconsistent since #1689 - the test cases specify the field, but it is ignored, we should definitely clean it up.

I'm yet wondering if it is preferable to drop the asserts or revert the ignoring. Can you provide some justification one way or another? It seems reasonable to assert cache fields in cache_test.

We should drop these assets. While some of the assertions in the cache test make sense, I don't think they make sense for the capacity accounting fields. I think for the capacity related fields we should be testing against higher level concepts - such as, for some ResourceFlavor, capacity, and isBorrowing. We should be able to test nominal/borrowing/lending/usage through just those two alone

[mimowo]

Yeah, I can imagine maintaining too low-level tests might be a chore.

For now, let's clean up (even if we end up asserting on ResourceGroups in the future), as in the current form the asserts are just confusing anyway.

We will need to find a testing strategy while working on #79.

/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: ddf214df1e4b772dfadcc92caa4d88363dbdb6b7

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: gabesaba, mimowo

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mimowo]

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