Allow unittesting indexes on the cache-backed reader

kubernetes-sigs / controller-runtime

Repo for the controller-runtime subproject of kubebuilder (sig-apimachinery)

Apache License 2.0

2.57k stars 1.16k forks source link

Allow unittesting indexes on the cache-backed reader #657

Open alvaroaleman opened 5 years ago

alvaroaleman commented 5 years ago

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: https://github.com/kubernetes/test-infra/pull/14830#discussion_r336232996 /kind feature

DirectXMan12 commented 5 years ago

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

alvaroaleman commented 5 years ago

@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 commented 5 years ago

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 commented 4 years ago

/help /priority backlog

k8s-ci-robot commented 4 years ago

@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](https://github.com/kubernetes-sigs/controller-runtime/issues/657): >/help >/priority backlog Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

fejta-bot commented 4 years ago

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 commented 4 years ago

/lifecycle frozen

alvaroaleman commented 2 years ago

For posterity, I did built something for this out-of tree some time ago that might be used as inspiration to add this to controller-runtime directly: https://github.com/kubernetes/test-infra/blob/682727078f0c86e556d9d766bd4ffbf3e2980a56/prow/tide/tide_test.go#L3836-L3923

alvaroaleman commented 2 years ago

It should also be mentioned that the "interact with cluster" part has been decoupled form the "run stuff" part and moved into pkg/cluster from pkg/manager in the meantime. So having something like a pkg/cluster/fake might be a good way forward here