Controller tests - mocked resource manager

[szoio]

What this PR does / why we need it:

• Mocked out the resource manager for the resource group, event hub, storage and key vault resources.
• Exposed the resource managers via interfaces to the respective controllers (by adding this interface as a property to each of the reconcilers.
• Created a environment variable switch TEST_CONTROLLER_WITH_MOCKS (true or false, default value true) that determines if the controller tests are run with mocked resource managers.
• Updated make test to run with mocks, and make test-existing to run direct with Azure.
• Reverted some of the changes enable running controller tests in parallel (not worth the bother in the end).
• Quite a few cleanups and small improvements.

When running with mocks, controller tests now take 5-6 seconds.

This PR refs #228

Special notes for your reviewer:

The mocked resource managers are quite crude and rudimentary as simple arrays of resources - would be nice to to this with generics if they existed!

If applicable:

• this PR contains documentation
• this PR contains tests

[frodopwns]

Hey @szoio sorry for the slow review here, been out of town. I will have a review submitted by EOD Monday!

[szoio]

Hey @szoio sorry for the slow review here, been out of town. I will have a review submitted by EOD Monday!

Thanks @frodopwns. I've updated the PR description to summarise the changes.
It's quite a big PR, but the changes are all quite straightforward and low complexity.

[frodopwns]

@szoio could you add me as a collaborator on your fork? Looks like my access went away.

[szoio]

@szoio could you add me as a collaborator on your fork? Looks like my access went away.

Added. I recreated my fork but forgot to add you back.

[frodopwns]

Everything is running fine. Takes about 4.5 minutes to run the full test suite. Still want to dig in a little more to see what kinds of issues it can catch.

[frodopwns]

Was able to catch a failure by commenting out the r.Update calls that set provisioning to true or false...this is good

have you tested any other scenarios that might result in failures being caught?

[frodopwns]

Do you think we should update the tests to also check that the resource exits provisioning state and enters provisioned state?

[szoio]

Do you think we should update the tests to also check that the resource exits provisioning state and enters provisioned state?

I think we should verify any of the states that matter to the controller.
If the resource enters or exists provisioning state is something that either the controller needs to verify as part of its implementation (e.g. before it returns success for a reconcile op), or in any way will result in some state changes that must be propagated to the cluster or anything like that, we should verify it.

If it doesn't affect the controller in any way, then we shouldn't test it, because we are neither trying to test the resource manger nor the sdk.

I think there is scope to improve the assertions we are making and make them more comprehensive in a lot of cases, whether we are using the mocks or the real resource manager.

[frodopwns]

👍 this looks like a good start, we can talk about abstracting this a bit more once we settle on a abstraction layer for the resource manager clients

[frodopwns]

might be a good idea to make sure the pipeline runs both test scenarios before merging this

[szoio]

might be a good idea to make sure the pipeline runs both test scenarios before merging this

Thanks @frodopwns for approving.
Yes the "Run Unit Tests" job runs against the mocks, and the "Set Kind cluster and Run unit tests" runs against the real resource managers.