Support reactor features in fake client

[grantr]

Reactors are a useful feature of the official client's fake implementation. They allow injecting errors, simulating the actions of other controllers, and tracking the actions of the controller under test instead of just the output. IIUC, none of those are possible with the current fake client.

[droot]

@fanzhangio Can you investigate how hard it will be to add reactors ?

[droot]

@grantr Have you considered using https://github.com/golang/mock.

[grantr]

@droot Can you give an example of how mocks would be used for this? What interface would I mock?

[DirectXMan12]

/kind feature

honestly, reactors might be a decent idea in theory, but in practice Kubernetes reactors tend to yield difficult-to-follow, brittle test code, IMO (as someone who's written or updated a number of reactor-based tests in the Kubernetes and OpenShift codebases)

we should think long and hard on the design before we opt for introducing them.

[DirectXMan12]

They allow injecting errors

Generally possible with a real API server for most errors (not found, conflict, etc), but I can understand a desire to easily simulate others.

simulating the actions of other controllers

Simulating the actions of other controllers generally isn't particularly hard if you have something that can store objects (either an actual API server or something that just tracks objects), since controllers are just updating state through normal API calls.

and tracking the actions of the controller under test instead of just the output

I'd assert we probably want to discourage this behavior -- you should generally be tracking if the controller yielded the desired state, not how it does that (granted, there are times you want to ensure things happen in a certain order, but that's rarer, and often can be worked around by splitting up the actual method that does the sync and/or using requeues)

[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

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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 rotten