Allow unittesting indexes on the cache-backed reader

[alvaroaleman]

Currently, the only way of testing if:

• An index actually gets added to the cache
• Using the index yields the expected result

is to use envtest, which spins up an etcd and apiserver. Doing so works fine, but requires more setup (the binaries must be available) and has a decent chance of flaking in CI, e.G. due to CPU starvation.

It would be nice if there was a way to test the two cases above via pure unittests.

Discussion originally started here: kubernetes/test-infra#14830 (comment)
/kind feature

[DirectXMan12]

I'm all ears for a good way to do this

[alvaroaleman]

@DirectXMan12 So what I had in mind would be something like:

• Add a new pkg/manager/fake that exposes a NewFakeManager(obj ...runtime.Object)
• All methods on that manager except for GetClient and GetFieldIndexer will error or panic
• GetClient and GetFieldIndexer can be used to create and use an index, something along the lines of https://github.com/kubernetes/test-infra/blob/f0e45d49993ce6aec651c981bbed9805d016ccc3/prow/tide/tide_test.go#L3192-L3252

WDYT?

[DirectXMan12]

All methods on that manager except for GetClient and GetFieldIndexer will error or panic

:-/ I'm not a huge fan of this, but if we can't figure out a better method, it might be a viable way forward. Usually, this means that there's an overbroad interface, but in this case it's "set of available dependencies", so it might be fine.

[vincepri]

/help
/priority backlog

[k8s-ci-robot]

@vincepri:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help
/priority backlog

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[vincepri]

/lifecycle frozen